Git運用 レッスン3
プルリクエストとレビュー
変更をレビューしてもらうためのプルリクエストの作り方と、レビューを受ける・行う際のポイントを学ぶ
レビューしやすいプルリクエストを作る
プルリクエスト（PR）は、レビュアーが素早くコンテキストを理解できるように作ることが重要です。 タイトルには変更内容を、説明文には背景と確認方法を書きます。
## What（何を変更したか）
注文履歴ページにページネーションを追加しました。
## Why（なぜこの変更が必要か）
Issue #482 の対応。注文件数が多いユーザーで一覧表示が遅延していた。
## How（どのように実装したか）
- 1ページ20件のオフセットベースのページネーションを実装
- APIレスポンスにtotalCountを追加
## Testing（確認方法）
- [ ] 注文が21件以上のアカウントで2ページ目に遷移できることを確認
- [ ] 注文が0件のアカウントで空表示になることを確認
- [ ] 既存のユニットテストが通ることを確認
Closes #482PRのサイズも重要です。目安として変更行数200行程度までに 収まるよう分割すると、レビューの質が保たれやすくなります。 巨大なPRは「LGTM」と流し読みされるリスクが高まります。
レビューを受ける側の心構え
1
指摘はコードへのフィードバックとして受け取る
「このコードは」という指摘を、自分自身への否定と捉えすぎない
2
意図が伝わっていない場合は説明を加える
指摘に対してただ従うだけでなく、意図があれば対話する
3
レビュー待ちの時間を減らす工夫をする
PRを小さく保ち、レビュアーが確認しやすい状態にする
レビューを行う側の心構え
建設的なフィードバック
- • 「コードを批判し、人を批判しない」ことを意識する
- • 指摘には理由を添える（「こうすべき」だけでなく「なぜなら」）
- • 良い点も具体的に伝える
- • タイムリーにレビューする（目安: 24時間以内）
レビューの3つのステータス
- Approve: マージして良い状態
- Request Changes: マージ前に修正が必要
- Comment: 判断は著者に委ねる質問・提案
Draft PRとCIゲート
実装途中でもDraft PRとして公開することで、 設計方針を早い段階で確認してもらい、大きな手戻りを防ぐことができます。 また、多くのチームではCI（自動テスト・静的解析）がすべて緑になることを マージの必須条件として設定し、レビュアーがロジックの妥当性に集中できるようにしています。
ポイント
CIが落ちている状態でレビューを依頼すると、レビュアーの手間が増え、 フィードバックのサイクルも遅くなります。まずCIを通してからレビューを依頼しましょう。
ポイント
- • PRの説明文にはWhat/Why/How/Testingを書き、レビュアーの理解を助ける
- • PRは小さく（目安200行程度）保つことでレビューの質が向上する
- • レビューは「コードへの指摘」であり、著者個人への否定ではない
- • Approve / Request Changes / Commentを適切に使い分ける
- • Draft PRで早期にフィードバックを得て、大きな手戻りを防ぐ
- • CIが通ってからレビューを依頼するとフィードバックサイクルが速くなる
確認クイズ
1 / 3小さなプルリクエストが推奨される理由として最も適切なものはどれか？