はじめに

前回に続き、Git 運用についてまとめです。
今回は PR レビューのワークフローをまとめます。

以前上司の PR 内容の細かさに"レベルの違い"を感じたのは、今となっては良い思い出

PR レビューの目的

コードの品質を維持
マージ先ブランチ（develop）のコミット履歴を直線的に保つ

役割

レビュー担当者（レビュアー）
レビュー対象者（レビュイー）

レビュー前の準備

ブランチの最新化（レビュイー）

マージ先（developブランチ）から作業ブランチ（featureブランチ）に fast forward できる必要があります
できない場合は、以下の手順で Rebase を行います：

# カレント
git switch feature/#6-add-new-feature

# リポジトリを最新化
git fetch
   
# developブランチにRebase（コンフリクトがあれば解決）
git rebase origin/develop

変更をリモートに反映（レビュイー）

# --force-with-leaseで安全に強制プッシュ
git push --force-with-lease -u origin feature/#6-add-new-feature

レビューのプロセス

初回レビュー（レビュアー）

レビュアーが変更内容を確認
指摘事項を PR のコメントとして記載

修正対応（レビュイー）

# 必要に応じてdevelopブランチの変更を取り込む
git fetch
git rebase origin/develop
  
# コードを修正し、コミットする

# 修正をプッシュ（必要な場合は--force-with-lease付き）
git push -u origin feature/#6-add-new-feature

レビュー完了まで

レビュアーが修正内容を確認、レビュイーが修正対応を繰り返す

マージと後処理

PRのマージ（レビュアー）

修正が完了したら PR をマージ(クローズ)

ブランチの後処理 (レビュイー)

レビュアーが PR をマージする時に、画面からブランチを削除する
- 一時的な feature ブランチを削除。ただし、永続的なブランチは除く

おわりに

文字にするとスッキリしますね。PR 運用では"PRの記載粒度"がとても重要になります。
私を含め、実際に PR ワークフローを経験された方も、すっごく雑な PR を出してくる時があるので、しっかりと認識合わせが必要です。（この"PRの記載粒度"については実際の PR を見てもらうのが一番）
あと、PR からマージする際に Merge を行うのか、Rebase を行うのかも決まってないプロジェクトとかもあるので、今後まとめたいです。