女性向けエンジニアスクール
3秒でわかる
作業ブランチを main へ取り込む前に、差分を見せてレビューを頼む仕組み。壊れたコードが本番に入るのを防ぎ、変更の理由を記録として残す役割も持つ。
もう少し詳しく
どういうものか
自分のブランチで書いた変更を main などへマージする前に、差分をチームに見せて確認を頼む仕組みです。GitHub ではプルリクエスト、GitLab ではマージリクエストと呼びますが、やっていることは同じです。
作ると差分が行単位で表示され、レビュアーが気になる行に直接コメントを付けられます。修正して同じブランチに push すれば、プルリクエストの中身も自動で更新されます。承認が集まり、テストなどの自動チェックが通ってからマージする、という流れが一般的です。
なぜ必要か
第一に、壊れたコードが main に入るのを止めるためです。一人では見落とす条件漏れや命名のずれも、他人の目が入ると高い確率で拾えます。多くのチームは main への直接 push を禁止し、必ずプルリクエストを通す設定にしています。
第二に、記録として残るからです。半年後に「なぜこの実装にしたのか」を調べるとき、コードだけでは意図は分かりません。プルリクエストには背景の説明と議論の経緯が紐づいて残るので、当時の判断をたどれます。
第三に、レビューが学習の場になります。書き方の指摘を受け取る側にとっても、他人の差分を読む側にとっても、実際に動くコードを題材にできる機会です。
具体例
コマンドラインから作る場合の流れは次のとおりです。
git switch -c feature/add-search
# ファイルを編集する
git add .
git commit -m "検索フォームを追加"
git push -u origin feature/add-search
# GitHub CLI でプルリクエストを作る
gh pr create --base main --title "検索フォームを追加" --body "商品名で絞り込めるようにした"
gh pr status説明欄には「何を変えたか」よりも「なぜ変えたか」と「どう確認したか」を書くとレビューが速く進みます。
**変更の理由**
一覧が 200 件を超えて目的の商品を探せないという問い合わせがあったため
**確認したこと**
- 空文字で検索したとき全件が出ること
- 一致 0 件のとき「該当なし」が出ることつまずきやすいところ
似た用語との違い
| 用語 | 指すもの |
|---|---|
| プルリクエスト | 取り込みの依頼とレビューの場。GitHub 側の機能 |
| マージ | 実際にブランチを取り込む Git の操作 |
| コードレビュー | 差分を読んで指摘する行為そのもの |
プルリクエストは、コードレビューを経てマージへ至るまでの入れ物にあたります。