ギット
この回答には、GitHubも含まれています。
ローカルリポジトリ
Git（ローカル）には、.gitファイルをコミットするディレクトリ（）があり、これが「ローカルリポジトリ」です。これは、リモートリポジトリにすぐに追加してコミットするSVNなどのシステムとは異なります。
Gitは、ファイル全体を保存することで変更されるファイルの各バージョンを保存します。また、デルタの変更を通じて「再作成」せずに個々のバージョンに移動できるという点で、SVNとは異なります。
Gitはファイルをまったく「ロック」しないため、編集のための「排他ロック」機能を回避するため（pvcsなどの古いシステムが思い浮かびます）、オフラインのときでもすべてのファイルを常に編集できます。実際には、GitHubなどのリモートリポジトリへのプルまたはフェッチ/プッシュ中に、ファイルの変更を（同じファイル内で）マージするという驚くべき仕事をします。手動で変更する（実際にファイルを編集する）必要があるのは、2つの変更に同じコード行が含まれる場合だけです。
枝
ブランチを使用すると、メインコード（「マスター」ブランチ）を保持し、コピー（新しいブランチ）を作成して、その新しいブランチ内で作業できます。ブランチが作成されてから作業にしばらく時間がかかる場合、またはマスターが多くの更新を取得する場合は、マスターブランチに対してマージまたはリベース（履歴を改善し、競合を解決するのが容易になることが多い）を行う必要があります。完了したら、ブランチで行った変更をマスターリポジトリにマージします。多くの組織は、機能、バグ、または雑用の項目であるかどうかにかかわらず、作業の各部分にブランチを使用しています。他の組織は、バージョンのアップグレードなどの大きな変更にのみブランチを使用します。
フォーク：ブランチを使用してブランチを制御および管理しますが、フォークを使用すると、他の誰かがコードの受け入れを制御します。
大まかに言って、ブランチを行うには2つの主要なアプローチがあります。1つ目は、ほとんどの変更をマスターブランチで維持することです。バージョンの変更など、より長くて実行時間の長いものにのみブランチを使用して、異なるニーズに2つのブランチを使用できるようにします。2つ目は、基本的にすべての機能リクエスト、バグ修正、または雑用に対してブランチを作成し、それらのブランチを実際にメインマスターブランチにマージするタイミングを手動で決定することです。これは退屈に聞こえますが、これは一般的なアプローチであり、現在使用していて推奨している方法です。これにより、マスターブランチがよりクリーンになり、プロダクションにプロモートするのがマスターになるため、リベースおよびブランチのマージ。
ブランチをマスターにする標準的な方法は、を実行することmergeです。ブランチを「リベース」して履歴を「クリーンアップ」することもできます。現在の状態には影響せず、「よりクリーンな」履歴を提供するために行われます。
基本的には、特定のポイント（通常はマスター）から分岐するという考え方です。あなたが分岐してから、「マスター」自体がその分岐点から前進しました。ブランチで行ったすべての変更が、最新のすべての変更を含むマスターの現在の状態に対して行われる場合、「クリーン」になります（問題を解決するのが簡単になり、履歴が理解しやすくなります）。したがって、プロセスは次のとおりです。変更を保存します。「新しい」マスターを取得し、それに対して再度変更を適用します（これはリベース部分です）。マージと同じようにリベースすると、競合が発生し、手動で解決（つまり、編集および修正）する必要があることに注意してください。
注意すべき1つのガイドライン：
ブランチがローカルで、まだリモートにプッシュしていない場合にのみリベースしてください！
これは主に、リベースが自分のコミットを含む他の人が見る履歴を変更する可能性があるためです。
ブランチの追跡
これらは、名前が付けられたブランチですorigin/branch_name（とは対照的にbranch_name）。コードをリモートリポジトリにプッシュしたり、リモートリポジトリからプルしたりする場合、これは実際にはそれが発生するメカニズムです。たとえば、git pushというブランチを作成するとbuilding_groups、ブランチは最初に移動しorigin/building_groups、次にリモートリポジトリに移動します。同様に、を実行するgit fetch building_groupsと、取得されたファイルはorigin/building_groupsブランチに配置されます。次に、このブランチをローカルコピーにマージすることを選択できます。私たちの実践はgit fetch、単なるaではなく、常に手動でマージすることですgit pull（1つのステップで上記の両方を実行します）。
新しいブランチを取得しています。
新しいブランチを取得する：クローンの最初の時点では、すべてのブランチがあります。ただし、他の開発者がブランチを追加してリモートにプッシュする場合、それらをローカルにプルダウンできるようにするために、それらのブランチとその名前について「知る」方法が必要です。これはgit fetch、追跡ブランチ（例：）を使用して、すべての新しいブランチと変更されたブランチをローカルリポジトリに取得するa を介して行われますorigin/。一度fetch編集git branch --remoteすると、追跡ブランチをリストして、git checkout [branch]実際に特定のブランチに切り替えることができます。
マージ
マージは、異なるブランチまたは同じブランチの異なるバージョンからのコード変更を組み合わせるプロセスです（たとえば、ローカルブランチとリモートが同期していない場合）。ブランチで作業を開発し、その作業が完了し、準備ができてテストされている場合、masterブランチにマージできます。これはgit checkout master、masterブランチに切り替えることで行われgit merge your_branchます。マージは、すべての異なるファイルをもたらし、同じファイルへの異なる変更さえも一緒にします。つまり、ファイル内のコードが実際に変更され、すべての変更がマージされます。
行っているときcheckoutのmasterそれも行うことをお勧めしますgit pull origin masterリモート・マスターの非常に最新版を得るためにあなたのローカルマスタにマージ。リモートマスターが変更された場合、つまり、moved forwardその間にそれを反映する情報が表示されgit pullます。その場合（マスターが変更された場合）git checkout your_branch、次にrebaseマスターするようにアドバイスされ、変更が実際に「新しい」マスターの上に「リプレイ」されるようになります。次に、次の段落に示すように、マスターを最新の状態に保ちます。
競合がない場合、マスターには新しい変更が追加されます。競合がある場合、これは、同じファイルに、自動的にマージできないコード行の周りに変更があることを意味します。この場合git merge new_branch、解決すべき競合があると報告されます。ファイルを編集して（両方に変更が加えられます）、必要な変更を選択し、不要な変更の行を文字通り削除してからファイルを保存することで、それらを「解決」します。変更は、========およびなどの区切り記号でマークされ<<<<<<<<ます。
あなたは再び意志いかなる紛争解決たらgit addとgit commitそれらの変更のマージを継続するが（あなたを導くために、このプロセスの間にgitからのフィードバックを得るでしょう）。
プロセスがうまく機能しない場合は、git merge --abortリセットするのに非常に便利です。
インタラクティブなリベースとスカッシュ/並べ替え/コミットの削除
毎日 'work-in-progress'としてコードをコミットするなど、多くの小さなステップで作業を行った場合、多くの小さなコミットをいくつかの大きなコミットに「つぶす」ことができます。これは、同僚とコードレビューを行う場合に特に役立ちます。（コミットを介して）実行したすべての「ステップ」を再生するのではなく、1回のコミットでこの作業に対するすべての変更の最終結果（diff）をここに示したいだけです。
これを行うかどうかを検討する際に評価する重要な要素は、複数のコミットが同じファイルまたは複数のファイルに対して行われるかどうかです（その場合は、コミットをスカッシュする方がよい）。これは、インタラクティブなリベースツールで行われます。このツールを使用すると、コミットを押しつぶしたり、コミットを削除したり、メッセージを書き換えたりすることができます。たとえば、git rebase -i HEAD~10（注：はであり~、はありません-）以下が表示されます。
ただし注意して、このツールを「生々しく」使用してください。一度に1つのスカッシュ/削除/並べ替えを実行し、終了してそのコミットを保存してから、ツールを再入力します。コミットが連続していない場合は、それらを並べ替えることができます（その後、必要に応じてスカッシュします）。ここで実際にコミットを削除することもできますが、それを行うときは、本当に何をしているのかを確認する必要があります！
フォーク
Gitリポジトリでのコラボレーションには、主に2つの方法があります。1つ目は、上記で詳述したように、人々がプルしたりプッシュしたりするブランチを介して直接行われます。これらの共同編集者は、リモートリポジトリに登録されたSSHキーを持っています。これにより、そのリポジトリに直接プッシュできます。欠点は、ユーザーのリストを維持する必要があることです。他のアプローチ-フォーク-では、誰でもリポジトリを「フォーク」して、基本的に自分のGitリポジトリアカウントにローカルコピーを作成できます。次に、変更を加え、完了したら「プル要求」を送信して（実際には、実際のリポジトリメンテナーに対する「プル」要求と「プル」要求のほうが多い）、コードを受け入れます。
フォークを使用するこの2番目の方法では、誰かがリポジトリのユーザーのリストを管理する必要はありません。
GitHub
GitHub（リモートリポジトリ）は、そのようなリポジトリがある（または追加されている）場合に、コミットされた変更を通常プッシュおよびプルするリモートソースであるため、ローカルとリモートは実際にはかなり異なります。リモートリポジトリを考えるもう1つの方法は、リモートリポジトリが.gitディレクトリ構造であることです。
「フォーク」するとき-GitHub WebブラウザーGUIでこのボタンをクリックできます -GitHubアカウントに
コードのコピー（「クローン」）を作成します。初めて実行するときは少し微妙な場合があるので、コードベースがリストされているレポジトリ（元の所有者または「forked from」のいずれか）と、たとえば次のように確認してください。
ローカルコピーを取得したら、必要に応じて（ローカルマシンにプルしてプッシュすることにより）変更を加えることができます。完了したら、元のリポジトリ所有者/管理者に「プルリクエスト」を送信します（空想に聞こえますが、実際にはこれをクリックするだけです
）。彼らはそれを「プル」します。
コードを共同で作業するチームでより一般的なのは、リポジトリを「複製」することです（リポジトリのメイン画面で「コピー」アイコンをクリックします）。次に、ローカルに入力git cloneして貼り付けます。これにより、ローカルでセットアップされ、（共有された）GitHubの場所にプッシュおよびプルすることもできます。
クローン
GitHubのセクションで示したように、クローンはリポジトリのコピーです。リモートリポジトリがある場合、git cloneそのURLに対してコマンドを発行すると、リポジトリのローカルコピーまたはクローンが作成されます。このクローンには、すべて、ファイル、マスターブランチ、その他のブランチ、すべての既存のコミット、シバン全体が含まれます。追加とコミットを行うのはこのクローンであり、リモートリポジトリ自体がそれらのコミットをプッシュします。SVN、PVCS、CVSなどの従来のCVS（コードバージョン管理システム）とは対照的に、Git（およびMercurialなどのそれに類似したシステム）をDVCS（分散バージョン管理システム）にするのは、このローカル/リモートの概念です。リモートリポジトリに直接コミットします。
可視化
コアコンセプトの視覚化は、
http：//marklodato.github.com/visual-git-guide/index-en.htmlおよびhttp://ndpsoftware.com/git-cheatsheet.html#loc=indexで確認できます。
変更がどのように機能しているかを視覚的に表示したい場合、ビジュアルツールgitg（gitxmacOSの場合）を、「地下鉄の地図」（ロンドン地下鉄など）と呼ぶGUIで打ち負かすことはできません。物事の変化、分岐、統合など
変更を追加、コミット、管理するためにも使用できます！
gitg / gitxはごくわずかですが、GUIツールの数は増え続けています。多くのMacユーザーは、Brotherbardのgitxフォークを使用しています。Linuxの場合、優れたオプションは、直感的でありながら強力なインターフェイスを備えたsmart-gitです。
GUIツールを使用しても、コマンドラインで多くのコマンドを実行することに注意してください。
このために、~/.bash_aliasesファイルに次のエイリアスがあります（~/.bashrc各ターミナルセッションのファイルから呼び出されます）。
# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '
そして、私は自分の~/.gitconfigファイルに次の「gitエイリアス」を持っています-なぜこれらがあるのですか？
したがって、（TABキーを使用した）分岐の完了は機能します！
これらは次のとおりです。
[alias]
co = checkout
cob = checkout -b
使用例： git co [branch] <-ブランチのタブ補完が機能します。
GUI学習ツール
あなたは見つけることがhttps://learngitbranching.js.org/基本概念のいくつかの学習に便利。スクリーンショット：
ビデオ：
https //youtu.be/23JqqcLPss0
最後に、7人のキーライフセーバー！
変更を加え、追加してコミットします（ただしプッシュしないでください）。あなたはあなたがマスターであることを理解しています！
git reset [filename(s)]
git checkout -b [name_for_a_new_branch]
git add [file(s)]
git commit -m "A useful message"
Voila! You've moved that 'master' commit to its own branch !
ローカルブランチで作業中にいくつかのファイルをめちゃくちゃにして、最後に行ったときの状態に戻したいだけですgit pull。
git reset --hard origin/master # You will need to be comfortable doing this!
ローカルで変更を開始し、6ダースのファイルを編集してから、いや、まだマスター（または別の）ブランチにいます。
git checkout -b new_branch_name # just create a new branch
git add . # add the changes files
git commit -m"your message" # and commit them
現在のブランチで特定のファイルを1つ台無しにして、基本的にそのファイルをリモートリポジトリから最後にプルしたときの状態に変更（変更を失う）したい場合：
git checkout your/directories/filename
これは実際にファイルをリセットします（多くのGitコマンドと同様に、ここで何をしているのかよくわかりません）。
ローカルでいくつかの変更を行ったとき、git resetまたは変更中にそれらを失わないようにしたい場合rebase：cp -r ../my_project ~/Gitでめちゃくちゃになるか重要なものを失うかどうかわからない場合は、プロジェクト全体を手動でコピーします（）変更。
あなたはリベースしていますが、物事はめちゃくちゃになります：
git rebase --abort # To abandon interactive rebase and merge issues
GitブランチをPS1プロンプトに追加します（https://unix.stackexchange.com/a/127800/10043を参照）。たとえば、
ブランチはselenium_rspec_conversionです。
