マージとリベースの違い¶
原文¶
マージとリベースの違いを理解する：
たとえば、金曜日に機能の開発を終えたとします。 月曜日には、チームがすでに新しい変更をプッシュしています。 これであなたのブランチは古くなっています。
- マージすると → すべてが結合され、壊れるものはありませんが、履歴が乱雑に見えます。
- リベースすると → あなたのコミットが最新のコミットの上に積み重なり、履歴がきれいに見えます。
（前の投稿より）あなたのブランチは main から 200 コミット遅れています。どうしますか？
要約¶
merge: ブランチを結合してマージコミットを作る。安全・非破壊的だが履歴が複雑になる。 rebase: コミットを最新のmainの先頭に「積み直す」。履歴が直線的できれいだが、共有ブランチには使ってはいけない（コミットIDが変わる）。
解説¶
マージ vs リベース 比較¶
| 観点 | merge | rebase |
|---|---|---|
| 安全性 | 高（元のコミットを変更しない） | 低（公開済みブランチに使うと危険） |
| 履歴 | 非線形（マージコミットあり） | 線形（きれい） |
| コンフリクト対応 | 1回まとめて解決 | コミットごとに解決が必要な場合も |
| 使いどころ | main ← feature のマージ、共有ブランチ | ローカルの整理、feature を main に追随させる |
実務での使い分け¶
- feature ブランチを最新 main に追随させる →
git rebase main（ローカルブランチなら安全） - feature を main にマージする → PR マージ（squash merge や merge commit）
- 公開済み・共有ブランチには rebase 禁止 → 他のメンバーの履歴が壊れる