Git：枝が増えると、何が動くのか

コミットとブランチ参照を分けて描き、分岐、fast-forward、2親のマージ、競合解消の意味を理解する。

コミットと、それを指す名前を分ける

Gitのコミットはスナップショットと親への参照などを持つ、履歴の記録です。図のBはAを親に持っています。灰色の矢印は、新しい記録から親へ向けて描いています。 時間が進む向きとは逆なので注意してください。

ブランチ main は、先端のコミットBを指す参照です。通常のブランチ上で作業しているとき、HEADは現在のブランチを指します。ここではdetached HEADは扱いません。

A、Bなどは説明用の短い名前で、実際のコミットIDではありません。Pro Git：ブランチの基本

git switch -c feature で新しいブランチを作って切り替えた場面です。mainとfeatureの二つが、同じBを指しています。HEADはfeatureを指すようになります。

図で増えたのは参照であり、AとBの別コピーがもう一組できたわけではありません。履歴の同じ部分を複数の参照からたどれます。

本文中のコマンドは説明用です。教材を作るために、あなたの作業ブランチを変更するコマンドを実行したわけではありません。

feature上で変更をコミットし、新しい記録Cができました。Cの親はBです。featureはCを指すようになり、mainはBのままです。

ブランチは、積み重ねた変更そのものの名前というより、履歴の先端を指す名前です。図の緑の参照が動き、過去のコミットは同じ場所に残ることに注目してください。

通常のコミットを作った場合、親のBを書き換えてCに変えるのではなく、Bを親に持つ別のコミットが作られます。履歴を書き換える操作は、この作品では扱いません。

mainへ切り替えて git merge feature を行う場面です。mainのBがfeatureのCの祖先で、分岐した別の変更がないなら、fast-forwardできます。

この場合はmainをCへ進めるだけで、新しいマージコミットは必要ありません。featureもCを指しています。ここでは、fast-forwardを許す通常の設定を前提とします。

「マージしたら必ず二つの親を持つ記録が増える」とは限りません。統合先が、相手の履歴上に既に含まれているかが分かれ目です。Pro Git：基本的なマージ

前のfast-forwardとは別の経路を考えます。Bで分岐した後、featureでCを作る一方、mainでもDを作った状態です。Bは共通の祖先ですが、CとDは互いの祖先ではありません。

この状態でmainをただCへ移すと、main側のDを統合したことにはなりません。両方の変更を反映した結果を作る必要があります。

図では、同じBから二本の履歴が伸びています。別のブランチ名があること自体と、コミットの履歴が実際に分岐していることは区別してください。

main上でfeatureを通常のマージにより統合します。Gitは共通の祖先Bと、それぞれの先端を基に変更を統合し、結果を新しいマージコミットMとして記録します。

MはDとCを親に持ち、mainはMを指します。featureはCのままです。以前のコミットが一つへ潰される操作ではありません。ここではsquashやrebaseによる統合とは区別しています。

図の二本の親への矢印は、どの履歴を統合したかの情報です。内容が自動で統合できた場合の、マージ完了後の状態を示しています。

自動で統合できない場合があります。例えば、共通の文を片方で「購入する」、もう片方で「予約する」に変え、Gitが両方を統合できなければ競合になります。

作業者が意図を確認して内容を解決し、解決済みのファイルをステージしてコミットします。同じ行を触ったら常に競合する、と機械的に決まるわけでもありません。

コミットは記録、ブランチは参照、マージは履歴と内容の統合。 どれが動くのかを分けて見ると、ブランチ図が操作の説明として読めるようになります。Pro Git：マージ競合