Git の merge と rebase の使い分け - 履歴の形・黄金律・やり直し方

「merge と rebase、結局どっちを使えばいいの？」——Git で必ずぶつかる疑問です。両者は最終的な中身は同じでも、履歴の形が変わります。違いと使い分け、そして「やらかした時の戻し方」を、Git 公式ドキュメントを一次ソースに整理します。

根本的な違い: 履歴の形

• merge: 2つのブランチをマージコミット（親が2つの特殊なコミット）で統合する。分岐した作業の痕跡がそのまま履歴に残る
• rebase: 自分のコミットを相手ブランチの先端に付け替え（再適用）し、直線的な履歴にする。元コミットは破棄され新しいコミット（別のSHA）が作られる

最終的なファイルの中身（スナップショット）は両者で同じです。違うのは到達するまでの履歴の見え方だけです。

[分岐した状態]
        C4   (feature)
       /
C1-C2-C3      (main)
 
[git rebase main（feature 上で実行）= 直線的]
C1-C2-C3-C4'  (feature)
 
[git merge feature（main で実行・分岐ありなら）= マージコミット]
C1-C2-C3---M  (main)   ※ M は C3 と C4 を親に持つ
       \   /
        C4

fast-forward / --no-ff / squash

--no-ff は「このブランチがあった」事実を履歴に残せます。squash は履歴を綺麗にできますが、個々のコミットの作者・日時が失われ、同じブランチを使い続けると衝突しやすくなります。

rebase の黄金律

公式（Pro Git）も「リポジトリ外にあり、他人が基に作業しているコミットを rebase するな」と明記しています。

interactive rebase で履歴を整える

PR を出す前の「コミット掃除」に最適なのが git rebase -i です。

git rebase -i HEAD~5

エディタで各コミットに操作を指定します。

行の並べ替えでコミット順も変えられます。コミットメッセージの整え方はConventional Commitsも参考に。

コンフリクト処理の違い

# 衝突を解決したら
git add <file>
git rebase --continue   # 次のコミットへ
git rebase --abort      # 中止して元に戻す

git add <file>
git commit              # マージコミットを作成
git merge --abort       # 中止

merge は基本1回の解決で済むのに対し、rebase はコミットごとに衝突が起こりうるのが大きな違いです。コミットが細切れだと「コンフリクト地獄」になりがちで、先に squash してから rebase すると楽になります。

git pull --rebase

git pull は既定で merge するため、取り込むたびにマージコミットが増えがちです。--rebase を使うと、自分のコミットをリモート先端に付け替えて履歴を直線的に保てます。

git pull --rebase
git config --global pull.rebase true   # 常に rebase で取り込む

やり直し方（ここが安心材料）

rebase / merge を「しくじった」時も、たいてい元に戻せます。

git reset --hard ORIG_HEAD   # rebase/merge/reset 直前の状態へ（1手前のみ）

git reflog                   # HEAD の移動履歴（HEAD@{n}）
git reset --hard HEAD@{3}    # n番目の状態に戻す

ORIG_HEAD は直前の1操作分しか覚えていないので、複数操作を挟んだら reflog（既定で履歴を一定期間保持）を使うのが確実です。進行中なら --abort で安全に中断できます。

使い分けの指針

考え方として、merge は「何が起きたかの記録」、rebase は「どう作ったかの物語」を残す、と捉えると選びやすいです。

まとめ

• merge は分岐を残す、rebase は直線的にする。最終的な中身は同じ
• fast-forward / --no-ff / squash でマージの履歴の残り方を選べる
• 公開済みコミットの rebase は厳禁（force push で他人の履歴を壊す）
• rebase -i で squash / fixup / reword。PR前の掃除に有効
• 失敗しても ORIG_HEAD / reflog / --abort で戻せる
• 共有は merge、ローカル整理は rebase が基本線

「中身は同じ、変わるのは履歴の形」と「共有ブランチは rebase しない」——この2点を押さえれば、merge / rebase の判断でもう迷いません。

参考リンク

• Pro Git: Rebasing（Git 公式）
• Pro Git: Basic Branching and Merging（Git 公式）
• git-rebase ドキュメント
• About merge methods on GitHub（GitHub Docs）
• Git コマンドとエイリアス（当ブログ）
• Conventional Commits ガイド（当ブログ）