rebase運用でコンフリクト地獄に陥ったときに使えるGitテクニック
はじめに
私は以前、超大人数での開発プロジェクトに参加していたことがあります。
そのプロジェクトでは以下のようなGitの運用ルールが設けられていました。
- 最新のdevelopブランチにrebaseする（マージコミット禁止）
- コミットを1つにsquashする
つまり、毎回「rebase + squash」が必要な運用です。
developブランチには毎日複数のPRがマージされ、自分のブランチとの乖離があっという間に大きくなっていきます。
いざマージしようとすると、コンフリクトの嵐。
通常のrebaseでは、コミットごとにコンフリクトが発生し、何度も同じようなコンフリクト解決を繰り返す羽目になりました。
時には先祖返りのような事故が発生することもあります。
そんな状況で、できる限りスマートかつ安全にrebase + squashをするために役立った手法を紹介します。
この記事で紹介する手法
# 1. マージベースを取得して一時ブランチを作成
git show-branch --merge-base origin/develop my-branch
# commitIdが表示されます
git checkout -b temp-branch commitId
# 2. 自分のブランチをsquash mergeして1コミットにまとめる
git merge --squash my-branch
git commit -m 'Commit Message'
# 3. 最新のdevelopにrebase
git rebase origin/develop
# コンフリクトがあれば解決して
git rebase --continue
# 4. 元のブランチを更新
git checkout my-branch
git reset --hard temp-branch
git branch -D temp-branch
共通祖先の時点から一時ブランチを作り、そこに自分の変更をsquash mergeして1コミットにまとめます。
その後、最新のdevelopにrebaseするので、developブランチとのコンフリクトが最小限で済みます。
そもそもマージじゃダメなの？
「普通にマージすればいいのでは？」と思うかもしれません。
結論から言うと、マージでも問題ない場合は多いです。
ただし、チームのルールや状況によっては使えないことがあります。
マージが使えないケース
チームがrebase/squash merge運用を採用している
チームによっては以下の理由でマージコミットを禁止していることがあります。
- 履歴が読みやすくなる
- revertやcherry-pickが1コミット単位でできる
マージでOKなケース
- 個人開発や少人数チーム
- マージコミットを許容するルール
- 変更の過程を履歴に残したい場合
チームのルール次第なので、まずはプロジェクトのルールを確認しましょう。
なぜこの手法が有効なのか
通常のrebaseでは、自分のブランチにあるコミット数だけコンフリクト解決が発生する可能性があります。
my-branch: A → B → C → D → fix → fix2 → fix3
↑
この7コミット分、それぞれでコンフリクトが起きうる
この手法では、まず自分の変更を1コミットにまとめてからrebaseするため、コンフリクト解決は1回だけで済みます。
temp-branch: (squashされた1コミット)
↑
これだけ解決すればOK
どんな状況で使えるか
以下のような条件が重なると、この手法が特に有効です。
プロジェクトの特徴
- 大人数が同じリポジトリにコミットしている
- developブランチに毎日複数のPRがマージされる
- 共通ファイル（設定ファイル、共通コンポーネントなど）を複数人が触る
- レビュー待ちが長い
チームのルール
- squash mergeまたはrebase merge運用
- 直線的できれいなコミット履歴を求められる
注意点
force pushが必要
この手法を使うと、ブランチの履歴が書き換わります。リモートにpushするには強制pushが必要です。
git push -f origin my-branch
# または、より安全な --force-with-lease
git push --force-with-lease origin my-branch
--force-with-lease は万が一他の人が同じブランチを触っていて、リモートが更新されていた場合にpushを中断してくれるので、こちらを使う習慣をつけておくと安心です。
他の人と共有しているブランチでは使わない
自分だけが使っているfeatureブランチでのみ使用してください。他のメンバーと共有しているブランチで履歴を書き換えると、他のメンバーの作業に影響が出ます。
force pushをするので、他のメンバーの作業を消してしまうことにもなりかねません。
コミット履歴は失われる
squashするため、個別のコミット履歴は失われます。個別の細かな過程を残したい場合は、この手法は適していません。
もっとシンプルな代替手段
コンフリクトが少ない場合は、普通のrebaseで十分です。
git rebase origin/develop
ただし、コンフリクトが多い場合は、コミットごとに解決が必要になるため、本記事の手法の方が楽です。
まとめ
- 通常は
git rebaseやGitHubのSquash mergeで十分 - 大人数開発で乖離が大きくなり、コンフリクトが多発する状況で有効
- 「コンフリクト解決を1回で済ませたい」ときの切り札として覚えておくと便利
大規模プロジェクトで同じような状況に遭遇した方の参考になれば幸いです。
