はじめに
feature ブランチを最新の main に追従させたいとき、git merge main と git rebase main のどちらを使えばいいのか迷ったことはないでしょうか。私自身、「どちらもブランチを取り込む操作」くらいの理解で、履歴の見え方やコンフリクトの扱いがどう変わるのかが曖昧なままでした。この記事で違いを整理します。
結論
- merge は履歴を保存する（分岐と合流がそのまま残る）
- rebase は履歴を書き換えて一直線にする（コミットのハッシュが振り直される）
- 共有ブランチには merge、自分のローカル作業の整理には rebase が基本
merge：統合コミットで束ねる
git merge main は、両ブランチの変更をまとめたマージコミットを新しく1つ作ります。
- 元のコミット履歴・分岐はそのまま残る（非破壊的）
- 「いつ何が枝分かれして合流したか」が履歴に残る
- そのぶん履歴は分岐・合流でグラフ状になる
* マージコミット
|\
| * feature のコミット
* | main のコミット
|/
* 分岐点
rebase：土台を付け替える
git rebase main は、feature の各コミットを一旦退避し、main の先端を新しい土台として順に載せ直します。
- 結果、feature が「main の続き」として一直線の履歴になる（マージコミットが生まれず、きれい）
- ただしコミットのハッシュが振り直される＝履歴の書き換えになる
* feature のコミット（載せ直し）
* main の最新
* main のコミット
* 分岐点
使い分けの原則
| 観点 | merge | rebase |
|---|---|---|
| 履歴 | 分岐・合流が残る（事実に忠実） | 一直線（読みやすい） |
| コミット | 改変しない | ハッシュが振り直される |
| 共有済みブランチ | ✅ 安全 | ⚠️ 避ける |
| コンフリクト | 1回でまとめて解消 | コミットごとに解消することがある |
最重要の注意：rebase の黄金律
公開・共有済みのブランチを rebase してはいけません。
他人が持っている履歴を書き換えると、push 時に食い違いが生じ、--force push が必要になります。その結果、共同作業者の履歴が壊れてしまいます。rebase は「まだ自分しか持っていないローカルのコミット」に対して使うのが安全です。
よくある使い方
- feature を main の最新に追従させ、履歴をきれいに保ちたい場合:
git switch feature
git rebase main
- main に feature を取り込む（チーム運用・PR）場合:
git switch main
git merge feature # または PR 上でマージ
まとめ
- 履歴を「事実の記録」として残したいなら merge
- 履歴を「読みやすい物語」に整えたいなら rebase（ただしローカル限定）
- 共有済みブランチの rebase は厳禁
用途に応じて選べば、どちらも強力な武器になります。