こんにちは、かつコーチです。
Issueで課題を見える化できたら、次はその課題を解決するための変更を、実際にプロジェクトへ取り込んでもらう番です。
その仲立ちをしてくれるのが、GitHubのPull Request（プルリクエスト、通称PR）です。
この記事では、Pull Requestがどんな役割を持つ機能なのか、基本の作成から確認までの流れを解説します。
読み終える頃には、自分の変更を安全にチームへ提案できるようになります。
Pull Requestとは？
Pull Request＝「この変更を本線に取り込んでいいですか」という提案書
Pull Requestとは、自分がブランチ上で行った変更を、他のブランチ（多くはmainブランチ）に取り込んでほしいと提案する機能です。
たとえるなら、Pull Requestは「この変更を本線に取り込んでいいですか」という提案書を提出する行為だとイメージしてください。
チーム開発では、いきなりmainブランチに直接変更を書き込むのではなく、まず別のブランチで作業し、その内容をPull Requestという提案書にまとめてから、チームに確認してもらいます。
提案書には「何を」「なぜ」変更したのかを書き添え、他のメンバーがその内容を確認してから、本線（main）へ合流させるかどうかを判断する、という流れになっています。
なぜPull Requestが必要なのか
もし誰でも自由にmainブランチへ直接変更できてしまうと、確認前のバグが本番のコードに混入してしまうリスクがあります。
Pull Requestという提案書のプロセスを挟むことで、他のメンバーの目でチェックしてから取り込む、という安全な合流の仕組みが実現できます。
これは、稟議書を回さずに誰でも会社の重要な方針を勝手に決められてしまう状態を防ぐのと似ています。
提案書として一度形にすることで、レビューという確認のステップを踏めるようになるのです。
Pull Requestの基本的な作成手順
手順1：作業用のブランチを作成する
mainブランチを直接編集せず、まずは作業用のブランチを切ります。
git switch -c feature/add-login-validation
これは、提案書を書くための下書き用の紙を、本線とは別に用意するイメージです。
手順2：変更をコミットしてpushする
ブランチ上でファイルを編集したら、コミットしてリモートにpushします。
git add .
git commit -m "ログインフォームにバリデーションを追加"
git push -u origin feature/add-login-validation
手順3：Pull Requestを作成する
GitHubのリポジトリ画面を開くと、「Compare & pull request」というボタンが表示されるので、そこから作成画面に進みます。
GitHub CLIを使っている場合は、ターミナルからも作成できます。
gh pr create --base main --head feature/add-login-validation \
--title "ログインフォームにバリデーションを追加" \
--body "8文字未満のパスワードでエラーメッセージが表示されない不具合を修正 (#12)"
タイトルと本文には、「何を」「なぜ」変更したのかを具体的に書くことで、レビューする側が提案の意図を理解しやすくなります。
つまずきやすい設定・注意点
Pull Requestを作成する際は、送り先のブランチ（base）と、自分の変更が入っているブランチ（head）を取り違えないよう注意しましょう。
baseを間違えると、意図しないブランチに変更を取り込もうとしてしまいます。
よくあるつまずきポイント・エラー対処
1つのPull Requestに変更を詰め込みすぎた話
私が実際にチーム開発の練習で経験した失敗が、これでした。
❌ Before
ログイン機能の修正、ボタンの見た目調整、READMEの更新という、関係のない3つの変更を1つのブランチにまとめてコミットし、そのまま1つのPull Requestとして提出してしまいました。
分厚い提案書に、まったく別の議題を3つも詰め込んで提出したようなもので、レビューする側からは「どこから確認すればいいのかわからない」と指摘されてしまいました。
✅ After
改めて、変更内容ごとにブランチとPull Requestを分けることにしました。
# ログイン機能の修正だけを含むブランチ
git switch -c fix/login-validation
# 見た目調整は別ブランチで
git switch main
git switch -c style/update-button
1つのPull Requestには1つの目的だけを含めるようにしたところ、レビューがスムーズに進むようになりました。
この経験から、「提案書は1件につき1つの議題にまとめる」という感覚が、良いPull Requestの基本だと学びました。
応用・一歩先の使い方
Draft Pull Requestで作業中の状態を共有する
まだ作業が完成していない段階でも、「Draft pull request」として提出しておくことで、チームに進捗を共有できます。
gh pr create --draft --title "作業中：決済フローの見直し" \
--body "実装途中です。方向性についてフィードバックをください"
これは、提案書の下書き段階でチームに見せて、「今こんな方向で進めていますが、大丈夫でしょうか」と早めに確認をとるイメージです。
方向性がずれたまま作業を進めてしまうリスクを、早い段階で防ぐことができます。
まとめ
この記事のポイント
- Pull Requestとは、「この変更を本線に取り込んでいいですか」という提案書のような機能
mainを直接編集せず、作業用ブランチで変更してから提案するのが基本の流れ- タイトル・本文には「何を」「なぜ」変更したのかを具体的に書く
- 1つのPull Requestには1つの目的だけを含めると、レビューがスムーズになる
次に読むべき記事
提案書としてPull Requestを提出できたら、次はその提案をどう確認・承認してもらうかを学びましょう。
「コードレビューの進め方（コメント・Approve・変更依頼）」で、実際のレビューの流れを解説しています。