Git mergeとは
Gitでは、機能追加や修正をmainとは別のbranchで進め、作業が完了したらその変更をmainへ統合できます。この「別の開発履歴を現在のbranchへ取り込む」操作が git merge です。
最初に覚えておきたい重要な原則は、mergeは「現在いるbranch」に「指定したbranch」を取り込む操作だということです。
たとえば、feature-demo の変更を main へ取り込みたい場合は、先に main へ移動してから次を実行します。
git switch main
git merge feature-demo
git merge feature-demo を実行したとき、取り込み先は main、取り込み元は feature-demo です。逆のbranchにいる状態で実行すると、意図と逆方向のmergeになるため注意します。
merge前に状態を確認する
merge前には、まず現在のbranchと作業ツリーの状態を確認します。
git status
git branch
Git公式ドキュメントでも、merge前には自分の作業を整理し、基本的にはcommit済みの状態にしておくことが推奨されています。未commit変更がmerge対象と重なる場合、Gitはmergeを停止します。
安全な学習手順では、次の状態を確認してからmergeします。
- 取り込み先branchにいる
- 必要な変更がcommitされている
git statusで意図しない変更が残っていない
branchを作って変更する
例として、mainから feature-demo branchを作ります。
git switch main
git switch -c feature-demo
ファイルを変更したら状態を確認します。
git status
変更をstageし、commitします。
git add .
git commit -m "Add demo change"
ここまでで、feature-demo にだけ新しいcommitが存在する状態になります。
mainへmergeする
変更をmainへ取り込むには、まずmainへ戻ります。
git switch main
状態を確認します。
git status
問題がなければ、feature-demoをmergeします。
git merge feature-demo
merge後は必ず結果を確認します。
git status
git log --oneline --graph --decorate --all
git status は現在の作業状態、git log --graph はbranchとcommitの履歴構造を確認するために使えます。
fast-forwardとは
mainからfeature-demoを作ったあと、main側に新しいcommitが増えていない場合を考えます。
A---B main
\
C feature-demo
この場合、mainはfeature-demoの履歴上にそのまま進むことができます。
git switch main
git merge feature-demo
すると概念的には次の状態になります。
A---B---C main, feature-demo
Git公式ドキュメントでは、このように現在のbranchの先端が取り込み元commitの祖先である場合、新しいmerge commitを作らずbranchポインタを進める動作をfast-forwardと説明しています。
つまりfast-forwardでは、merge操作は行われていますが、merge専用の新しいcommitは作られません。
merge commitとは
branchを分けたあと、main側にもfeature側にも別々のcommitが追加された場合は履歴が分岐します。
C---D feature-demo
/
A---B---E mainこの状態でmainからfeature-demoをmergeすると、単純にmainのポインタを前へ進めるだけでは両方の履歴を表現できません。
競合せず自動統合できれば、Gitは両方の履歴を親として持つmerge commitを作成します。
C---D
/ \
A---B---E---M mainこの M がmerge commitです。
初学者の段階では、次の区別で十分です。
- fast-forward：履歴が一直線なのでbranchポインタを前へ進められる
- merge commit：履歴が分岐しているため、両方を結ぶ新しいcommitを作る
merge後は履歴を図で確認する
mergeはコマンドが成功しただけで終わりにせず、履歴を確認すると理解しやすくなります。
git log --oneline --graph --decorate --all
fast-forwardなら履歴はほぼ一直線に見えます。merge commitが作られた場合はbranchが分岐し、再び合流する形が表示されます。
この表示を毎回見る習慣をつけると、「今どのbranchにいて、どのcommitがどこへ統合されたのか」を理解しやすくなります。
mergeがうまくいかないとき
最初に確認するコマンドは次の2つです。
git status
git log --oneline --graph --decorate --all
git status では、未commit変更、merge途中の状態、競合ファイルなどを確認できます。
履歴の関係が分からなくなった場合は git log --graph でbranchの位置関係を確認します。
merge conflictが発生した場合は、Gitは自動で統合できなかった箇所を残して停止します。これはmergeそのものの失敗ではなく、人間による判断が必要な状態です。conflictの詳細な解消方法は別テーマとして扱います。
複雑な競合が発生し、merge開始前へ戻したい場合には次のコマンドがあります。
git merge --abort
ただし、merge開始前から複雑な未commit変更があると元の状態を完全に再構成できない場合があるため、やはりmerge前に作業状態を整理しておくことが重要です。
安全なmergeの基本手順
基本形は次の流れです。
git switch main
git status
git merge feature-demo
git status
git log --oneline --graph --decorate --all
ポイントは、mergeコマンドそのものよりも、merge前後の状態確認をセットにすることです。
Gitではbranchを自由に作成できますが、どのbranchへ何を取り込んだかを理解できなければ履歴管理の意味が薄れます。git status と git log --graph を組み合わせることで、mergeを「なんとなく成功した操作」ではなく、確認可能な履歴操作として扱えます。
まとめ
git merge は、指定したbranchの変更を現在のbranchへ統合するコマンドです。
まずは次の3点を押さえれば十分です。
- 取り込み先branchへ先に移動する
git merge <取り込み元branch>を実行するgit statusとgit log --graphで結果を確認する
さらに、履歴が一直線ならfast-forward、履歴が分岐していればmerge commitが必要になる場合がある、と理解しておくとGitの履歴構造が見えやすくなります。
branchは作業を分離する仕組み、mergeは分離した作業を再び統合する仕組みです。この2つをセットで理解すると、mainを直接編集し続ける運用から、安全に変更を分離・検証・統合するGit運用へ進めます。
参考資料
- Git公式
git mergeDocumentation: https://git-scm.com/docs/git-merge - Git公式 User Manual「How to merge」: https://git-scm.com/docs/user-manual
