Git mergeの仕組み — 別々に直したメモを合わせてみよう

ひよこ

別々のブランチで直したメモは、どう合わせるの？

ペンギン先生

git mergeで、今いるブランチへ相手の変更を統合できるよ。分岐後に両方が進んだ基本例では、共通祖先と両側の内容を比べる。まず新しい練習用リポジトリで2つの変更を合わせよう。

ひよこ

3ウェイの3は、3人で作業する意味？

ペンギン先生

共通祖先、今いる側、取り込む側の3つの版を使う意味だよ。今回の例ではmainがノートを追加し、featureがメニューを変更する。以前から何が変わったかをそれぞれ比べられるんだ。

ひよこ

共通祖先は、いつもブランチを作った地点？

ペンギン先生

単純な分岐ならそう考えやすいけれど、すでに統合した履歴等によって違うよ。共通祖先が複数の場合もあり、ortでは祖先を統合した木を基準にすることもあるんだ。

ひよこ

fast-forwardは、マージと違うの？

ペンギン先生

今いる先端が取り込む先端の祖先なら、通常は参照を前へ進めるだけで済むよ。新しいマージコミットを作らない。--no-ff等の指定で動きも変わるので、mainが進んだかだけでなく履歴の関係を見るんだ。

ひよこ

衝突は、同じ行を直したときだけ？

ペンギン先生

典型的には同じ部分の異なる変更だけど、削除と変更、名前変更等でも起こるよ。Gitが自動で合わせられない部分を示す。自動で統合できても、アプリの意味が正しいかは確認が必要なんだ。

ひよこ

衝突したら、片方を選べばいい？

ペンギン先生

目的に合う最終内容へ編集して、マーカーを取り除き、動作や差分を確認するよ。両方を組み合わせる場合もある。意味を理解せず全部oursやtheirsへ任せる操作は避けよう。

ひよこ

rebaseなら、同じ結果でも履歴が違う？

ペンギン先生

変更を別の基点へ再適用するので、通常コミットIDが変わるよ。mergeは両側の履歴を統合する。共有済みの履歴を書き換える場合はチームの手順が重要で、どちらが常に良いと決めないんだ。

ひよこ

途中でやめたいとき、戻せる？

ペンギン先生

マージが途中ならgit merge --abortが候補だよ。ただし開始前の未コミット変更があると、完全に戻せない場合がある。先に作業を整理するのが大切。下の練習は新しいフォルダーだけで行おう。

まずは、2つの変更を合わせる

Gitの統合は、以前の内容とそれぞれの変更を見比べるところから理解できます。Gitが使えるなら、新しい空の練習用フォルダーで試しましょう。以下はGit Bash（Windows）やmacOS/Linuxのsh系シェル用で、PowerShellへそのまま貼る手順ではありません。

git init -b main
git config user.name "Merge Demo"
git config user.email "demo@example.invalid"
printf 'drink=tea\n' > menu.txt
git add menu.txt
git commit -m "最初のメモ"

git switch -c feature
printf 'drink=juice\n' > menu.txt
git add menu.txt
git commit -m "飲み物を変更"

git switch main
printf 'bring=ticket\n' > note.txt
git add note.txt
git commit -m "持ち物を追加"
git merge feature --no-edit
cat menu.txt note.txt
git log --oneline --graph --all

メモの結果は次の2行です。履歴のコミットIDは環境ごとに違います。

drink=juice
bring=ticket

mainもfeatureも分岐後に進んだため、この例では両側を親に持つマージコミットができます。名前とメールの設定はこの練習用リポジトリ内だけの指定です。既存の仕事のリポジトリでは行いません。

共通祖先と2つの先端を見る

共通祖先ではdrink=teaだけがあります。featureはdrink=juiceへ変更し、mainはnote.txtを追加しました。Gitは両方の変更を合わせます。取り込む側と取り込み先だけでなく、以前の共通の内容も使うことが3ウェイの基本です。

履歴が単純な分岐なら共通祖先を出発点と見られますが、複雑な統合履歴では複数の候補等もあります。自動統合されたことだけで、組み合わせたプログラムが正しく動く保証にはなりません。

fast-forwardと衝突を分ける

今いる先端が相手の先端の祖先なら、通常のfast-forwardではブランチの参照を進め、新たなマージコミットを作りません。—no-ffで作る選択もあります。—no-commitだけではfast-forwardを途中で止められないので、検査用の指定にも注意します。

両側が同じ部分を違う値へ変えた場合、Gitが判断できず衝突することがあります。削除と変更等でも起こります。衝突マーカーは、どちらかが正しいという判定ではありません。目的に合う内容を作り、差分と動作を確認してからgit addとgit merge —continue等へ進みます。

もう少し詳しく：中断・戦略・rebase

途中のマージを中断するgit merge —abortは、開始前に未コミット変更があると元へ完全に戻せない場合があります。先にコミットや適切な退避で作業を整理し、git statusで状態を確かめます。

通常の2先端の統合はortが既定です。Git 2.50以降のrecursiveという名前はortの同義です。古い独立したrecursiveの性能説明を、そのまま現行版へ当てはめません。-X oursという衝突時の選択と、相手の木を無視するours戦略も別です。

rebaseは変更を別の基点へ再適用し、通常コミットIDが変わります。共有した履歴に行う場合はチームの手順を確認します。rerereは以前の解決を再利用する助けですが、再適用された内容も確認します。

🐧 ペンギン先生のまとめ：「Git merge」って出てきたら「共通の前の版を見ながら、別々の変更を合わせること」と思えばだいたいOK！

基本操作はGit入門、日々の検証はGitHub Actions入門で続けて見てみましょう。

参考資料

• Git：git merge — 3ウェイ・fast-forward・衝突・abort・現行の戦略
• Git：git rebase — 再適用と共有履歴の条件
• Git：git rerere — 以前の衝突解決の再利用と確認