チーム開発では、コードを書くだけでなく Pull Request（PR）の運用ルール も非常に重要です。
ルールが曖昧なまま運用すると、
- 何を変更したPRなのか分かりづらい
- レビューに時間がかかる
- 見落としが増える
- マージ事故が起きやすい
といった問題につながります。
今回は、実務でよく使われる Pull Request運用ルール をまとめて紹介します。
Pull Requestとは？
Pull Requestとは、自分の変更内容を他のブランチへマージしてもらうための依頼です。
例えば、
feature/login
↓
develop
feature/login で作業した内容を develop へ取り込んでもらう際にPRを作成します。
1. 1PR 1目的を徹底する
最も重要なルールです。
悪い例
- ログイン機能追加
- ヘッダー修正
- CSS微調整
- エラーメッセージ文言変更
これらを1つのPRにまとめる
良い例
- ログイン機能追加 → 1PR
- ヘッダー修正 → 別PR
- 文言修正 → 別PR
実務ポイント
PRの目的を1つに絞ることで、
- レビューしやすい
- 不具合時に切り戻ししやすい
- 差分確認が楽
になります。
2. PRタイトルは変更内容が分かるようにする
悪い例
修正
対応
変更
良い例
ログイン画面のバリデーションエラー表示を修正
ユーザー一覧APIの検索条件追加
実務ポイント
タイトルだけで内容が分かる状態が理想です。
タスク管理システムの通番等がある場合は、通番を明記することでタスクとPRが紐づきやすくなります。
3. PR本文テンプレートを統一する
実務ではテンプレート化している現場が多いです。
## 概要
ログイン画面のエラーメッセージ表示不具合を修正
## 変更内容
- バリデーション条件修正
- エラーメッセージ文言変更
## 確認観点
- 正常ログイン
- パスワード未入力
- ID未入力
## 備考
関連チケット: #123
実務ポイント
レビュー観点が明確になり、確認漏れを防げます。
4. 差分はできるだけ小さくする
大きすぎるPRはレビューしづらいです。
悪い例
100ファイル変更
2000行差分
良い例
5〜15ファイル程度
変更目的が明確
実務ポイント
差分が小さいほどレビュー速度が上がります。
ただし、名称の一括置換系作業では対象ファイルが必然と多くなってしまう事があります。
その場合は、置換したワードのリストを明記し置換作業のみ行うようにしましょう。（置換作業＋修正作業のPRは非推奨）
また、あまりにも対応範囲が大きくなってしまう場合は、事前に周知（コンフリクト防止）や少し分割する等の工夫をしましょう。
5. スクリーンショットを添付する
画面系の修正ではかなり重要です。
修正前
修正後
の比較画像を載せるとレビューがしやすくなります。
実務ポイント
UI変更系では必須にしている現場も多いです。
また、テストクラスを用意している現場ではテストが成功しているエビデンスを載せることもあります。
6. 動作確認手順を書く
レビュアーが同じ手順で確認できるようにします。
1. ログイン画面を開く
2. パスワード未入力でログイン
3. エラーメッセージ表示を確認
実務ポイント
再現手順があるだけでレビュー品質が大きく変わります。
7. レビュー指摘への対応ルール
指摘を受けたら修正し、コメントで返信します。
ご指摘ありがとうございます。
該当箇所を修正しましたのでご確認お願いします。
実務ポイント
対応した内容を明確に残すことが大切です。
よくある運用ルール
よくあるルールとして以下があります。
- 自己マージ禁止
- 承認2名以上でマージ
- CI通過必須
- コンフリクト解消後に再レビュー
現場によってルールは異なります。
現場のルールをしっかり把握して作業を行いましょう。
まとめ
Pull Request運用では以下を意識するとスムーズです。
- 1PR 1目的
- タイトルを明確にする
- 本文テンプレートを統一
- 差分を小さくする
- 確認手順を記載する
PRの質が上がると、チーム全体の開発効率も大きく向上します。