Git のマージ戦略：rebase と merge commit がチーム運用に与える実際の差

要点

rebase と merge commit の選択は、履歴の見た目の問題ではなく、障害調査とレビューの運用コストに直結する判断である。チームの規模とリリース頻度によって、最適解は変わる。

何が実際に変わるのか

rebase は履歴を直線化し、merge commit はブランチの合流点を保持する。この違いが最も効くのは、障害発生時に git bisect で原因コミットを二分探索するときである。直線化された履歴は bisect が機能しやすい一方、頻繁な force-push は共有ブランチを壊すリスクを伴う。Git 公式ドキュメントの rebase の章でも、公開済みブランチへの rebase は避けるよう明記されている。

レビューとの相性

merge commit を残す運用では、プルリクエスト単位でレビュー差分がまとまり、後から「いつ・何が・なぜ」統合されたかを追いやすい。ただし、コミット数が多いブランチでは、レビュアーが個々のコミットではなくマージ後の差分全体を見ることになり、粒度の細かいレビューがしづらくなる。一方で rebase 運用は、squash と組み合わせることでコミット単位のレビューを維持しやすいが、レビュー中に force-push が入るとレビュアー側の差分表示が崩れるという運用上の摩擦がある。Pro Git（Chacon & Straub 著）の公表資料でも、公開ブランチに対する rebase は履歴を壊す操作として明確に区別されている。

チーム規模別の指針

数名規模で全員が Git の操作に習熟している場合、rebase 運用は履歴を追いやすく、CI の実行結果とコミットの対応関係も明確になる。十数名を超え、外部貢献者が関わる場合は、force-push 事故のリスクが無視できなくなるため、merge commit を基本としつつ squash merge を選択的に使う折衷案が現実的である。リポジトリを分割するか統合するかという、より上位の構成判断はモノレポとポリレポの選択基準にも関わってくる。

結局のところ、正解は一つではなく、bisect の頻度、レビュー体制、貢献者の習熟度という三つの軸で決めるべき運用判断である。