ブランチが main から 200 コミット遅れている。merge か rebase か？¶
原文¶
Interviewer:
Your branch is 200 commits behind main. What will you do?
Merge or rebase?
要約¶
200 コミット遅れたフィーチャーブランチの対応は「状況によって異なる」が正解。共有ブランチなら merge、個人ブランチで履歴を綺麗にしたいなら rebase。ただし 200 コミットの rebase は競合リスクが高く、interactive rebase でのスカッシュも選択肢。
回答¶
状況に応じて判断する。ただし原則は：
- 個人ブランチ（まだ push していない / 他者が使っていない） →
git rebase mainで履歴を整理 - 共有ブランチ（他の人も使っている） →
git merge mainで安全にマージ - 200コミット差があり競合が怖い → まず
git merge mainでコンフリクト解消後、必要ならgit rebase -iでコミットを整理
解説¶
merge vs rebase の基本¶
| 観点 | merge | rebase |
|---|---|---|
| 履歴 | マージコミットが残る | 線形履歴になる |
| 安全性 | 元のコミットを変更しない | コミット SHA が書き換わる |
| 共有ブランチ | ◎ 安全 | ✗ 他者の環境が壊れる |
| 個人ブランチ | △ 履歴が複雑になる | ◎ 推奨 |
200 コミット差の場合の実践的アドバイス¶
# まず差分を確認
git log --oneline main..HEAD # 自分のコミット数
git log --oneline HEAD..main # mainが進んでいるコミット数
# 個人ブランチの場合
git fetch origin
git rebase origin/main
# コンフリクトが出たら都度解消
# 競合が多すぎる場合は一旦mergeして整理
git merge origin/main
# 解消後に必要なら
git rebase -i HEAD~N # 自分のコミットをまとめる
# 共有ブランチの場合
git merge origin/main # 安全なマージ
200 コミット差で rebase する際のリスク¶
- 競合（conflict）が大量に発生する可能性がある
- 1コミットずつ競合解消が必要になり時間がかかる
git rebase --abortでいつでも中断可能
面接での答え方¶
「まずブランチが共有されているか確認します。個人ブランチなら
git rebase mainで線形履歴を保ちますが、200コミット差では競合リスクが高いので、先にgit merge mainで最新化してからgit rebase -iでコミットを整理することも検討します。共有ブランチなら必ずgit mergeを選びます。」
→ 関連: mergeとrebaseの違い