ギット

多くの人が GitHub についても質問しているので、この回答には GitHub も含まれます。

ローカルリポジトリ

Git (ローカル) には、ファイルをコミットするディレクトリ ( .git) があり、これが「ローカル リポジトリ」になります。これは、リモート リポジトリにすぐに追加してコミットする SVN などのシステムとは異なります。

Git は、ファイル全体を保存することで、変更されたファイルの各バージョンを保存します。また、この点では SVN とは異なり、デルタ変更によって「再作成」することなく、任意の個別のバージョンに移動できます。

Git はファイルをまったく「ロック」しないため、編集時の「排他ロック」機能 (pvcs などの古いシステムが思い浮かびます) を回避し、オフラインの場合でもすべてのファイルを常に編集できます。Git は、GitHub などのリモート リポジトリへのプルまたはフェッチ/プッシュ中に、ファイルの変更 (同じファイル内) をマージするという驚くべき仕事を実際に行います。手動で変更 (実際にファイルを編集) する必要があるのは、2 つの変更が同じコード行に関係する場合のみです。

支店

ブランチを使用すると、メイン コード (「マスター」ブランチ) を保存し、コピー (新しいブランチ) を作成して、その新しいブランチ内で作業することができます。作業に時間がかかる場合や、ブランチの作成後にマスターに多くの更新がある場合は、マスター ブランチに対してマージまたはリベース (履歴の精度が向上し、競合の解決が容易になるため、こちらの方が望ましい) を行う必要があります。作業が完了したら、ブランチで行った変更をマスター リポジトリにマージします。多くの組織では、機能、バグ、雑用項目など、作業ごとにブランチを使用しています。他の組織では、バージョン アップグレードなどの大きな変更にのみブランチを使用しています。

フォーク: ブランチではブランチを制御および管理しますが、フォークでは他の誰かがコードの受け入れを制御します。

大まかに言えば、ブランチを作成するための主なアプローチは 2 つあります。1 つ目は、ほとんどの変更をマスター ブランチに保持し、バージョンの変更など、異なるニーズに合わせて 2 つのブランチを用意したい大規模で長期的な作業にのみブランチを使用する方法です。2 つ目は、基本的に機能リクエスト、バグ修正、雑用ごとにブランチを作成し、それらのブランチをメインのマスター ブランチに実際にマージするタイミングを手動で決定する方法です。これは面倒に思えますが、一般的なアプローチであり、現在私が使用し、推奨している方法です。マスター ブランチがクリーンな状態になり、マスターを本番環境に昇格させるため、ブランチのリベースとマージによって、完了してテストされたコードのみが必要になるためです。

ブランチをマスターに取り込む標準的な方法は、 を実行することですmerge。ブランチを「リベース」して履歴を「クリーンアップ」することもできます。これは現在の状態には影響せず、よりクリーンな履歴を作成するために行われます。

基本的に、あるポイント (通常はマスター) から分岐するという考え方です。分岐してから、「マスター」自体はその分岐ポイントから前進しています。ブランチで行ったすべての変更を、最新の変更がすべて含まれた現在のマスターの状態に対して適用すると、「よりクリーン」になります (問題の解決が容易になり、履歴が理解しやすくなります)。したがって、プロセスは次のようになります。変更を保存し、「新しい」マスターを取得し、それに対して変更を再適用します (これがリベースの部分です)。マージと同様に、リベースによって競合が発生する可能性があり、手動で解決 (編集と修正) する必要があることに注意してください。

注意すべきガイドラインが 1 つあります。
ブランチがローカルにあり、まだリモートにプッシュしていない場合にのみ、リベースを実行
してください。これは主に、リベースによって、他のユーザーが参照する履歴が変更され、その履歴に自分のコミットが含まれる可能性があるためです。

ブランチの追跡

origin/branch_nameこれらは、（ ではなく）名前が付けられたブランチですbranch_name。リモート リポジトリにコードをプッシュしたり、リモート リポジトリからコードをプルしたりする場合、これは実際にそれが行われるメカニズムです。たとえば、git pushというブランチを作成するとbuilding_groups、ブランチは最初に に移動しorigin/building_groups、次に がリモート リポジトリに移動します。同様に、 を実行するとgit fetch building_groups、取得されたファイルはブランチに配置されます。その後、このブランチをローカル コピーにマージすることを選択できます。当社では、（上記の両方を 1 つの手順で実行する）だけではなく、origin/building_groups常に と手動マージを実行することを実践しています。git fetchgit pull

新しいブランチを取得しています。

新しいブランチの取得: クローンの初期段階では、すべてのブランチが存在します。ただし、他の開発者がブランチを追加してリモートにプッシュした場合、ローカルにプルダウンできるように、それらのブランチとその名前を「知る」方法が必要です。これは、git fetch追跡ブランチ (例: ) を使用して、すべての新しいブランチと変更されたブランチをローカル リポジトリに取得するによって行われますorigin/。fetchを実行すると、git branch --remote追跡ブランチを一覧表示して、git checkout [branch]実際に任意のブランチに切り替えることができます。

マージ

マージとは、異なるブランチ、または同じブランチの異なるバージョン (たとえば、ローカル ブランチとリモートが同期していない場合) からのコード変更を組み合わせるプロセスです。ブランチで作業を開発し、その作業が完了し、準備が整い、テストが完了したら、その作業をブランチにマージできますmaster。これは、でブランチgit checkout masterに切り替えてから で行います。マージにより、すべての異なるファイル、さらには同じファイルへのさまざまな変更が1 つにまとめられます。つまり、すべての変更をマージするために、ファイル内のコードが実際に変更されることになります。mastergit merge your_branch

checkoutの を実行するときは、 を実行して、リモート マスターの最新バージョンをローカル マスターにマージすることmasterもお勧めします。リモート マスターが変更された場合 (つまり ) 、その 中にそれを反映する情報が表示されます。その場合 (マスターが変更された場合) 、 を実行してから をマスターに実行し、変更が実際に「新しい」マスター上で「再生」されるようにすることをお勧めします。その後、次の段落に示すように、マスターを最新の状態に維持する を続行します。git pull origin mastermoved forwardgit pullgit checkout your_branchrebase

競合がない場合、master に新しい変更が追加されます。競合がある場合、同じファイルに、自動的にマージできない類似のコード行に関する変更があることを意味します。この場合、git merge new_branch解決すべき競合があることが報告されます。競合を解決するには、両方の変更を含むファイルを編集し、必要な変更を選択して、不要な変更の行を文字通り削除してから、ファイルを保存してください。変更は、 や などの区切り文字でマークされ========ます<<<<<<<<。

競合を解決したら、もう一度それらの変更をgit add行ってgit commitマージを続行します (このプロセス中に、ガイドとなる git からのフィードバックが提供されます)。

プロセスがうまく機能しない場合は、git merge --abortリセットすると非常に便利であることがわかります。

インタラクティブなリベースとコミットの圧縮/並べ替え/削除

多数の小さなステップで作業を行った場合、たとえば、毎日「進行中の作業」としてコードをコミットする場合、それらの多数の小さなコミットをいくつかの大きなコミットに「まとめる」ことをお勧めします。これは、同僚とコード レビューを行う場合に特に便利です。実行したすべての「ステップ」を (コミットを介して) 再現するのではなく、1 つのコミットでこの作業に対するすべての変更の最終結果 (差分) をここに示したいだけです。

これを実行するかどうかを検討する際に評価する重要な要素は、複数のコミットが同じファイルに対してなのか、それとも複数のファイルに対してなのか (その場合はコミットを圧縮する方がよい) です。これは、対話型リベース ツールを使用して行います。このツールを使用すると、コミットを圧縮したり、コミットを削除したり、メッセージを書き換えたりすることができます。たとえば、git rebase -i HEAD~10(注: これは であり~、 ではありません-) は、次のようになります。

ただし、このツールは慎重に使用してください。一度に 1 つの圧縮/削除/並べ替えを行い、終了してそのコミットを保存してから、ツールを再度開始します。コミットが連続していない場合は、並べ替えることができます (その後、必要に応じて圧縮します)。ここでコミットを削除することもできますが、その場合は何をしているのかを本当によく確認する必要があります。

フォーク

Git リポジトリでのコラボレーションには、主に 2 つのアプローチがあります。1 つ目は、上で説明したように、人々がプルおよびプッシュするブランチを直接経由する方法です。これらの共同作業者は、リモート リポジトリに SSH キーを登録しています。これにより、そのリポジトリに直接プッシュできます。欠点は、ユーザーのリストを管理する必要があることです。もう 1 つのアプローチであるフォークでは、誰でもリポジトリを「フォーク」して、基本的に自分の Git リポジトリ アカウントにローカル コピーを作成できます。その後、変更を加え、完了したら「プル リクエスト」を送信して (実際には、彼らからの「プッシュ」と実際のリポジトリ管理者への「プル」リクエストのどちらかになります)、コードを受け入れてもらいます。

フォークを使用するこの 2 番目の方法では、リポジトリのユーザー リストを管理する人は必要ありません。

GitHub

GitHub (リモート リポジトリ) は、そのようなリポジトリがある場合 (またはリポジトリに追加されている場合) に、コミットされた変更をプッシュおよびプルするリモート ソースです。そのため、ローカルとリモートは実際にはまったく異なります。リモート リポジトリを別の方法で考えると、.gitリモート サーバー上に存在するディレクトリ構造であると言えます。

'フォーク' すると (GitHub ウェブ ブラウザー GUI でこのボタンをクリックできます) 、GitHubアカウントにコードのコピー ('クローン') が作成されます。初めて行う場合は少しわかりにくいかもしれませんが、コード ベースが誰のリポジトリにリストされているか (元の所有者か、'フォーク元' か) を必ず確認してください。たとえば、次のようになります。

ローカル コピーを取得したら、必要に応じて変更を加えることができます (ローカル マシンにプルおよびプッシュすることによって)。完了したら、元のリポジトリの所有者/管理者に「プル リクエスト」を送信します (派手な名前に聞こえますが、実際にはこれをクリックするだけです: )。すると、所有者/管理者がそれを「プル」します。

コードを共同で作業するチームでは、リポジトリを「クローン」するのが一般的です (リポジトリのメイン画面で「コピー」アイコンをクリックします)。次に、ローカルで入力しgit clone て貼り付けます。これにより、ローカルでセットアップされ、(共有) GitHub の場所にプッシュおよびプルすることもできます。

クローン

GitHub のセクションで説明されているように、クローンとはリポジトリのコピーです。リモート リポジトリがある場合、git cloneその URL に対してコマンドを発行すると、リポジトリのローカル コピー、つまりクローンが作成されます。このクローンには、ファイル、マスター ブランチ、その他のブランチ、既存のすべてのコミットなど、すべてが含まれています。このクローンに対して追加やコミットを行い、リモート リポジトリ自体にそれらのコミットをプッシュします。このローカル/リモートの概念により、Git (および Mercurial などの類似システム) は、リモート リポジトリに直接コミットする SVN、PVCS、CVS などの従来の CVS (コード バージョン管理システム) とは対照的に、DVCS (分散バージョン管理システム) になります。

視覚化

コアコンセプトの視覚化は以下でご覧いただけます。
http://marklodato.github.com/visual-git-guide/index-en.htmlそして
http://ndpsoftware.com/git-cheatsheet.html#loc=index

gitg変更がどのように機能しているかを視覚的に表示したい場合は、私が「地下鉄マップ」（特にロンドン地下鉄）と呼んでいる GUI を備えたビジュアル ツール（ macOS 用）に勝るものはありgitxません。これは、誰が何を行ったか、物事がどのように変化し、分岐し、統合されたかなどを示すのに最適です。

また、変更を追加、コミット、管理するためにも使用できます。

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 '

[alias]
  co = checkout
  cob = checkout -b