写真と文章で詳しく解説！ Git の仕組みを理解する

この記事では、Git の動作原理について、主に画像と文章で詳しく説明することで関連知識を提供します。

git の仕組みの説明

この記事では、Git で最も一般的に使用されるコマンドを説明します。 Git の仕組みを少しでも理解している場合は、この記事を読むことでより完全に理解できるようになります。

上記の 4 つのコマンドは、作業ディレクトリ、ステージング ディレクトリ (インデックスとも呼ばれます)、およびウェアハウスの間でファイルをコピーします。

• git add files は、現在のファイルをステージング領域に配置します。

• git commit は、ステージング領域のスナップショットを生成し、送信します。

• git replace – files は、最後の git add ファイルを元に戻すために使用されます。また、git restart を使用して、すべての一時領域ファイルを元に戻すこともできます。

• git checkout – files は、ファイルをステージング領域から作業ディレクトリにコピーして、ローカルの変更を破棄します。

git replace -p、git checkout -p、または git add -p を使用して対話モードに入ることができます。

ステージング領域をスキップして、ウェアハウスからファイルを直接取得したり、コードを直接送信したりすることもできます。

• git commit -a は、git add を実行して、現在のディレクトリ内のすべてのファイルをステージング領域に追加して実行するのと同じです。

• git commit files最後のコミットと作業ディレクトリ内のファイルのスナップショットを含むコミットを作成します。そして、ファイルがステージング領域に追加されます。

• git checkout HEAD – ファイルをロールバックして最後のコミットをコピーします。

以下の本文では、以下の形式で画像を使用しています。

#緑の 5 桁の文字は送信された ID を表し、それぞれ親ノードを指します。ブランチはオレンジ色で表示され、特定のコミットを指します。現在のブランチは、それに接続されている HEAD によって識別されます。この写真は過去 5 件の提出物を示しています。ed489 が最新の提出物です。 master ブランチはこのコミットを指し、もう 1 つの maint ブランチは祖父母コミット ノードを指します。

Diff

コミット間の変更を表示するにはさまざまな方法があります。ここではいくつかの例を示します。

コミット

送信するとき、Git はステージング領域内のファイルを使用して新しい送信を作成し、その時点でノードを配置します。親ノードとして設定します。次に、現在のブランチが新しいコミット ノードを指すようにします。下の図では、現在のブランチがマスターです。コマンドを実行する前、マスターは ed489 を指しますが、送信後、マスターは ed489 を親ノードとする新しいノード f0cec を指します。

#現在のブランチが特定の送信の親ノードである場合でも、git は同じように動作します。以下の図では、master ブランチの祖父ノードである maint ブランチでコミットが行われ、1800b が生成されます。このようにして、maint ブランチは master ブランチの祖父母ではなくなります。このとき[1]のマージ(または[2]のリベース)が必要です。

コミットを変更する場合は、 git commit –amend を使用します。 Git は現在のコミットと同じ親ノードを使用して新しいコミットを作成し、古いコミットはキャンセルされます。

もう 1 つの例は、HEAD サブミッション [3] を分離することです。これについては後で説明します。

Checkout

Checkout コマンドは、履歴送信 (またはステージング領域) から作業ディレクトリにファイルをコピーするために使用され、ブランチを切り替えるためにも使用できます。

ファイル名が指定されている場合 (または -p オプションがオンになっている場合、またはファイル名と -p オプションが同時にオンになっている場合)、Git は指定されたコミットからファイルをコピーします。ステージング領域と作業ディレクトリ。たとえば、 git checkout HEAD~ foo.c は、コミット ノード HEAD~ (つまり、現在のコミット ノードの親ノード) にある foo.c を作業ディレクトリにコピーし、ステージング領域に追加します。 (コマンドでコミット ノードが指定されていない場合、コンテンツはステージング領域からコピーされます。) 現在のブランチは変更されないことに注意してください。

ファイル名が指定されていないが、(ローカル) ブランチが指定されている場合、HEAD 識別子はそのブランチに移動され (つまり、そのブランチに「切り替え」られます)、その後ステージング領域と作業ディレクトリが移動されます。のコンテンツは、HEAD に対応する送信ノードと一致します。新しい送信ノード (下図の a47c3) 内のすべてのファイルが (ステージング領域と作業ディレクトリに) コピーされます。古い送信ノード (ed489) にのみ存在するファイルは削除されます。上記 2 つのファイルは無視され、影響を受けません。

ファイル名もブランチ名も指定されていないが、タグ、リモート ブランチ、SHA-1 値、または master~3 などの類似したものが指定されている場合、匿名の名前が返されます。切り離された HEAD と呼ばれるブランチ (切り離された HEAD 識別子)。これにより、過去のバージョン間の切り替えが簡単になります。たとえば、Git のバージョン 1.6.6.1 をコンパイルする場合は、git checkout v1.6.6.1 (これはブランチ名ではなくラベルです) を実行し、コンパイルしてインストールし、別のブランチに切り替えることができます。 git チェックアウト マスターとして。ただし、コミット操作に「切り離された HEAD」が含まれる場合、以下で詳しく説明するように、動作が若干異なります。

公開アカウント「Java Backend Technology Full Stack」をフォローしてインタビューに返信すると、質の高いインタビュー資料が入手できます

HEAD ロゴがデタッチ状態にある コミット操作

HEAD がデタッチ状態 (ブランチにアタッチされていない) の場合、コミット操作は通常どおり続行できますが、名前付きブランチは更新されません。 (これは匿名ブランチの更新と考えることができます。)

マスターなどの別のブランチに切り替えると、このコミット ノードは (おそらく) 存在しなくなります。 available 参照されず破棄されます。このコマンドの後は、2eecb を参照するものは何もないことに注意してください。

ただし、この状態を保存したい場合は、コマンド git checkout -b name を使用して新しいブランチを作成できます。

Reset

Reset コマンドは、現在のブランチを別の場所にポイントし、オプションで作業ディレクトリとインデックスを変更します。作業ディレクトリに触れることなく、履歴リポジトリからインデックスにファイルをコピーするためにも使用されます。

オプションが指定されない場合、現在のブランチはそのコミットを指します。 -hard オプションを使用すると作業ディレクトリも更新され、-soft オプションを使用すると変更されません。

サブミッション ポイントのバージョン番号が指定されていない場合は、デフォルトで HEAD が使用されます。この方法では、分岐点は変更されませんが、インデックスは最後のコミットまでロールバックされ、–hard オプションが使用されている場合、作業ディレクトリは同じになります。

ファイル名 (または -p オプション) を指定した場合、インデックスが更新されることを除いて、動作効果はファイル名を使用したチェックアウトと同様です。

Merge

Merge コマンドは、異なるブランチをマージします。マージする前に、インデックスは現在のコミットと同じである必要があります。別のブランチが現在のコミットの親である場合、マージ コマンドは何も行いません。別の状況としては、現在のコミットが別のブランチの親である場合があり、早送りマージが発生します。ポインタは単純に移動され、新しいコミットが生成されます。

それ以外の場合は、実際のマージとなります。デフォルトでは、現在のコミット (以下に示す ed489) と別のコミット (33104) およびそれらの共通の祖父母ノード (b325c) の間で 3 方向のマージが実行されます [4]。その結果、まず現在のディレクトリとインデックスが保存され、次に親ノード 33104 とともに新しいコミットが作成されます。

チェリーピック

チェリーピックコマンドはコミットノードを「コピー」し、現在のブランチ上に同一の新しいコミットを作成します。 。

リベース

リベースは、コマンドをマージする代わりの方法です。 Merge は 2 つの親ブランチを 1 つのコミットにマージしますが、コミット履歴は直線的ではありません。リベースでは、現在のブランチ上の別のブランチの履歴が再生され、コミット履歴は線形です。本質的に、これは線形化された自動チェリーピッキングです。

上記のコマンドはすべて、master ブランチではなくトピック ブランチで実行され、master ブランチ上で繰り返され、ブランチが新しいノードを指すようになります。古いコミットは参照されず、リサイクルされることに注意してください。

ロールバック範囲を制限するには、-onto オプションを使用します。次のコマンドは、master ブランチ (2c33a) 上の 169a6 以降の現在のブランチの最後の数コミットを再生します。

git rebase –interactive もあります。これを使用すると、コミットの破棄、再配置、変更、マージなどの複雑な操作をより簡単に実行できます。これを示す画像はありません。詳細については、ここを参照してください: git-rebase(1)[5]。

ファイルの内容は実際にはインデックス (.git/index) や送信オブジェクトに保存されませんが、BLOB の形式でデータベース (.git/objects) に保存され、 SHA-1値のテスト。インデックス ファイルには、関連する BLOB ファイルとその他のデータが識別子とともにリストされます。送信の場合、それらはツリー形式で保存され、ハッシュ値によっても識別されます。ツリーは作業ディレクトリ内のフォルダーに対応し、ツリーまたはツリーに含まれる BLOB オブジェクトは対応するサブディレクトリおよびファイルに対応します。各サブミッションには、その上位レベルのツリーの識別コードが格納されます。

切り離された HEAD を使用して送信した場合、最後の送信は HEAD の reflog によって参照されます。ただし、しばらくすると無効になり、最終的には git commit –amend や git rebase と同様にリサイクルされます。

推奨学習: 「Git チュートリアル 」

以上が写真と文章で詳しく解説！ Git の仕組みを理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。