はじめに
前回に続き、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 を行うのかも決まってないプロジェクトとかもあるので、今後まとめたいです。