発端
Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？
— codehex.bsky（へっくす） (@codehex) 2024年2月25日
ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。
git commit --fixup
このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コミットにrebaseします。こうすることで、最終的に見えるコミットは非常にきれいなものになります。
fixup周りのひととおりのフローは下記が参考になると思います。どのコミットに対する修正なのか紐付けされるので、レビュー指摘事項の修正に関するコミットを新たに積み上げるより、効率よくわかりやすいと思います。
個人的な意見ですが、「レビュー指摘事項の修正」のようなコミットはあまり積み上げても情報量が少ない関係であまり嬉しいことはなく、fixupで綺麗に整理しておくのが無難だと思います。squash & mergeしている場合は別ですが…。
fixupコミットをrebaseし忘れる問題
一点問題があるとすれば、fixup!とついたコミットをrebaseして綺麗にし忘れる問題です。これをしてしまっては、情報量のほとんどないコミットログを何個も積み上げてしまいます。
こうした問題にはCIでの対処が有効です。GitHub Actionsを利用しているようであれば、下記のアクションが利用できます。
あるいは、「そのプルリクエストの中に含まれるコミットの中に登場するfixup!メッセージを含む行をカウントし、1以上だった場合はエラーとする」といったスクリプトを用意して対処する手もあります。
追記: lazygitだとかなり楽にできます
私は普段lazygitでコミット関係を管理しているのですが、lazygitもしっかり対応しています。
