Git のリベース vs マージ: どう使い分ける?

Git の rebase と merge は似ているようで全く違う操作です。チームの作法を決めるときに必ず議論になるテーマを、5 分で整理します。

1 分で復習

• merge: 2 つのブランチをひとつのコミット (マージコミット) で結合。履歴は分岐したまま残る
• rebase: 自分のコミット群を相手ブランチの先端に付け替える。履歴は一本道になる

merge が向く場面

• 複数人が触る共有ブランチへ取り込むとき
• 「いつどのブランチから入ったか」を監査ログとして残したいとき
• GitHub の Merge commit / Squash merge で PR 履歴を統一したいとき

rebase が向く場面

• PR 提出前に自分のトピックブランチを最新化したいとき (fast-forward にできる)
• コミットを意味のある単位に再編 (squash / reword) したいとき
• 履歴の読みやすさを重視するプロジェクト

絶対にやってはいけないこと

他の人が pull 済みのブランチに対して force push や rebase をしない。

共有済みコミットを書き換えると、他メンバーのローカル履歴と整合性が崩れ、復旧に膨大な時間が必要になります。rebase はローカルブランチ / 自分しか見ていないブランチに限定しましょう。

チームの合意項目チェックリスト

• main へのマージは Squash か Merge か、Rebase か
• PR 直前の同期は rebase か merge か
• コミットメッセージ規約 (Conventional Commits を使うか)
• force push はいつ許容されるか

この 4 点を README に書くだけで、初参加メンバーが混乱するリスクが大きく減ります。