rebase で色々あったので、備忘録として簡単に書いていきます。
前提背景
開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。
Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。
このような理由から、私はrebaseを積極的に使用しています。
何があったのか
簡単に言うと、レビュー中にブランチ元の変更があったので、 git rebase からの git push -f origin [ブランチ名] やったらレビュアーのコメントが吹き飛びました。
いやー、めっちゃ怒られたよね💦
原因
「レビュー中」という状況がまずかった。
コードを共有している状況で git push -f、つまり force push すると以下の問題が発生します。
レビューコメントの紐付けが失われる
GitHub上でレビュアーが特定のコミットに対してコメントを残している場合、そのコミットを書き換えると、コメントが「outdated」とマークされます。force push により元のコミットがリポジトリの履歴から削除されると、それに関連するコメントも適切なコンテキストを失うことがあり、レビュー過程での参照が難しくなります。
レビューの進行がリセットされる
force push により、既に検討されていた変更点が上書きされるため、レビュアーが再度同じコードを確認し直さなければならないことがあります。これはレビュープロセスを遅らせ、追加の作業を発生させます。
履歴の整合性が損なわれる
force push は、リポジトリの公開履歴を書き換えるため、他の開発者が既にチェックアウトまたはブランチに基づいて作業していた場合、彼らのローカル履歴との整合性が崩れます。これにより、不必要なコンフリクトが発生し、チーム内での混乱が発生します。
どうすれば良いか・対処法
共有しているブランチ、特にレビュー中のものに対しては、force push は避けるべきだというのが私の結論です。
ブランチ元で変更があった場合
ブランチ元で変更があった場合は以下のように対応した方が良いです。
- レビュー前、push前：git rebase
- レビュー中、push後：git merge
↑で変更を取得するようにすると、今回のような問題にはならないと思います。
最後に
rebase と、force push は計画的に・・・