かもメモ

自分の落ちた落とし穴に何度も落ちる人のメモ帳

Git fast-forward な状態にして update branch で master を取り込んだ commit を残さずに済むための git rebase

git GitHub Tips

チーム開発のGitリポジトリだとPR出してる間に別のブランチがmasterにマージされて、PRをマージするためにmasterを取り込んで…というような事が割とあるかと思います。そうすると、masterを取り込む際にMerged 'master' into <your_branch>って感じのmerge commitが作成されます。

create merge &#x27;master&#x27; commit

塵も積もれば山となる。このmasterを取り込んだmerge commitが大量にあるとログが見づらい...

PR を fast-forward な状態にする

fast-forward とは？

merge する親ブランチの最新コミットからブランチが作成されている状態
fast-forward merge

GitHub とかの PR だと master に merge した際の merge-commit が作成されるけど、ローカルなどコマンドで git merge した場合は merge-commit が作成されない状態が fast-forward な状態

fast-forward merge

rebase で fast-forward な状態にする

git rebase <マージしたいブランチ名> で現在のブランチを親ブランチの先頭 (HEAD) から生えている状態にすれば fast-forward な merge ができるようになる。
GitHub の様なリモートリポジトリの場合は

$ git rebase origin/master

とすればOK。

fast-forward merge

PR を fast-forward な状態にしておけば update branch で master を取り込んだログを残さずに済むので、master のログの見通しが良くなります。

ただし副作用に注意する

  • rebase しているので元のコミットハッシュとは異なるハッシュになってしまう
  • rebase すると履歴が変わってしまうので force push (-f)しなければならなくなる
  • rebase する featureブランチを複数人で使用しているなら、fast-forward な状態にするのは force push が必要なので master に merge する直前だけにしたほうが無難
  • master に取り込まれたものとコンフリクトを起こす物がある場合は rebase 中での修正にバグが混入する可能性があり、何か問題があったときに原因を探すのが困難になる可能性がある
  • rebase でコンフリクトが発生しない場合でも、ライブラリのバージョンの変更などで先に master に追加されていた機能にバグを発生させる可能性はある

cf.

所感

コードレビューが完了して merge できる状態なら git rebase origin/master で fast-forward な状態にすれば、不要な master を取り込んだ marge コミットを残さずに済む。
ただ rebase でコンフリクトが発生する時は、master を marge してコンフリクトを解消したコミットを残すほうが安全そう。コンフリクトが発生してない場合でも rebase した PR はCIのテストやステージングなどで動作確認を通すのが良いかなと思いました。

結局 rebase は履歴の改ざんしてるってことを心がけましょうって感じ。

[参考]

入門git

入門git