Git mergeの仕組み

まずGitは2つのブランチの「共通祖先（Common Ancestor）」を探すんだ。例えばmainからfeatureブランチを切った地点のコミットだね。そこから「mainで何が変わったか」と「featureで何が変わったか」を比較して、両方の変更を統合するよ。これを3ウェイマージ（3-way merge）って呼ぶんだ。

比較に使う3つのバージョンのことだよ。共通祖先（Base）、マージ先（Ours/main）、マージ元（Theirs/feature）の3つ。なぜ共通祖先が必要かというと、2つのファイルだけ比較しても「どっちが変更した側か」がわからないからなんだ。共通祖先と見比べることで、「mainが変えた部分」「featureが変えた部分」「両方変えた部分」を正確に判定できるよ。

ファストフォワード（fast-forward）は特殊なケースだよ。featureブランチを切った後にmainに何も変更がなかった場合、mainのポインタをfeatureの先頭にスライドさせるだけで済むんだ。マージコミットは作られない。一方、mainにも変更があった場合は本当のマージ（true merge）が行われて、2つの親を持つマージコミットが作られるよ。

3ウェイマージで「同じファイルの同じ行を両方のブランチが変更した」場合にコンフリクトが起きるよ。例えば共通祖先では3行目が「hello」だったのに、mainでは「Hello World」に、featureでは「こんにちは」に変えていたら、Gitはどっちを採用すればいいかわからない。そこでコンフリクトマーカー（<<<<<<<、=======、>>>>>>>）を挿入して人間に判断を委ねるんだ。

代表的なのはrecursive戦略（Git 2.33以前のデフォルト）とort戦略（Git 2.34以降のデフォルト）だね。recursiveは共通祖先が複数ある場合に、祖先同士を再帰的にマージして仮想的な共通祖先を作る。ort（Ostensibly Recursive's Twin）はrecursiveの改良版で、同じ結果をより高速に出せるよ。あとoctopus戦略は3つ以上のブランチを一度にマージできる特殊なものだけど、コンフリクトがある場合は使えないんだ。

マージは「2つの流れを合流させる」操作で、履歴がそのまま残る。リベースは「featureのコミットをmainの先頭に付け替える」操作で、直線的な履歴になるよ。内部的にはリベースは各コミットを1つずつcherry-pick（パッチ適用）しているんだ。マージコミットが残る方がチームの作業履歴が追いやすいけど、リベースの方がgit logがきれいになる。チームのルール次第だね。

rerere（Reuse Recorded Resolution）という機能があるよ。git config rerere.enabled trueで有効にすると、コンフリクトの解決方法をGitが記録してくれる。次に同じコンフリクトが発生したとき、前回の解決方法を自動適用してくれるんだ。長期間並行開発しているブランチを定期的にマージするようなケースでは、かなりの手間が省けるよ。

マージコミットは「いつ、どのブランチからどのブランチに統合したか」という重要な情報を持っているよ。git logで--graphオプションをつけると、ブランチの分岐と合流が視覚的にわかるんだ。リベースで直線にしてしまうとその情報が消える。特にリリースブランチへのマージや大きなfeatureの統合では、マージコミットを残しておいた方がトラブル時に原因を追いやすい。git bisectでバグ混入コミットを探すときも、マージの境界がわかると効率的だよ。