修正用ブランチでREADMEを直し、GitHubへpushできた。次は、その変更をmainへ取り込みたい。でも、取り込む前にほかの人にも確認してほしい。
そんなときに使うのが、Pull Requestです。変更の目的と差分をまとめて提示し、コメントやレビューを通じて、取り込んでよいかを判断します。
この記事では、前回までのブランチ・差分・push・マージの知識をつなぎ、変更の提案からレビュー、修正、マージまでを説明します。READMEの修正は説明用の例です。GitHub公式資料に基づく入門記事として整理しました。
1. Pull Requestは、変更を取り込むための提案
Pull Requestは「このブランチの変更を、こちらのブランチへ取り込みたい」という提案です。よく「PR」と略されます。
GitHubでは、PRに変更の説明、コミット、差分、コメント、チェック結果などを集められます。変更を取り込む前に、内容を共有して話し合う場所になります。GitHub公式：Pull Requestについて
前回の記事のgit pullとは別のものです。git pullは手元へ履歴を取得して取り込むコマンドで、Pull RequestはGitHub上で変更を提案する仕組みです。
| 項目 | 意味 |
|---|---|
| git pull | 手元へ履歴を取得して取り込むコマンド |
| Pull Request | GitHub上で変更を提案する仕組み |
PRを作成しただけでは、取り込み先のブランチへ変更は反映されません。実際に取り込む操作がマージです。
2. 変更を作る人と、確認する人の流れ
作業を、次のように分けて考えると理解しやすくなります。
| 段階 | 変更を作る人 | 確認する人 |
|---|---|---|
| 準備 | ブランチで編集し、確認・コミット・pushする | 必要なら事前に方針を相談する |
| 提案 | PRに目的、変更内容、確認結果を書く | 説明と差分を読む |
| レビュー | 質問に答え、必要な修正を行う | 気になる箇所へコメントし、判断を伝える |
| 再確認 | 修正を同じブランチへpushする | 更新された差分を確認する |
| 取り込み | 条件を確認してマージする | チームで決めた条件の充足を確認する |
これは、この記事で使う一般的な作業例です。誰がマージするか、何人の承認が必要かは、チームとリポジトリの運用によって異なります。
レビューは、コードの書き方を指摘するだけではありません。変更の目的、利用者への影響、抜けたケース、確認した内容などを、差分と合わせて見ます。READMEや記事原稿の変更も、PRで確認できます。
→作成者：PRに目的・変更内容・確認結果を書く
→確認者：説明と差分を読み、コメントと判断を伝える
→作成者：質問に答え、必要な修正を同じブランチへpush
→確認者：更新された差分を再確認
→作成者：質問に答え、必要な修正を同じブランチへpush
→チームで決めた取り込み条件を確認
→チームで決めた取り込み条件を確認
→条件を満たしたらマージ
3. baseとcompareを確認して、PRを作る
ここからは、共有リポジトリへ修正用ブランチをpushする権限があり、feature/readme-guideをGitHubへ送信済みの例です。
READMEに「原稿はarticlesフォルダーに保存します」という説明を追加し、mainへ取り込みたいものとします。
GitHubでリポジトリを開き、修正用ブランチを選びます。案内が表示されていれば「Compare & pull request」から作成できます。案内がない場合は、Pull requestsの画面から新しいPRを作り、比較するブランチを選びます。
| 項目 | この例で選ぶもの | 意味 |
|---|---|---|
| base | main |
変更を取り込む先 |
| compare | feature/readme-guide |
変更を提案する側 |
タイトルと説明を入力する前に、方向と差分を確認します。関係のないファイルやコミットが含まれていたら、原因を確認してから進めます。GitHub公式：Pull Requestの作成
取り込み先と変更側を逆にすると、別の提案になります。「どちらへ何を取り込むのか」を言葉にして確認しましょう。
権限がないリポジトリでは、forkした自分のリポジトリからPRを提案する方法もあります。今回は、同じ共有リポジトリのブランチ同士を対象にします。
- compare：feature/readme-guide（変更を提案する側）READMEの変更を提示 ↓
- Pull Request：方向と差分を確認して変更を提案マージすると変更が反映される ↓
- base：main（変更を取り込む先）
4. レビューしやすい説明を書く
差分だけでは「なぜ変えたのか」が伝わりません。PRの説明には、変更の目的、何を変えたか、どう確認したかを書くと、確認する人が判断しやすくなります。
次は、README修正の説明例です。「確認したこと」の内容は、実際に行った確認だけを書いてください。
タイトル：READMEに記事原稿の保存場所を追加
## 変更の目的
初めて作業する人が、原稿を置く場所を判断できるようにします。
## 変更したこと
READMEに、記事原稿はarticlesフォルダーへ保存する説明を追加しました。
## 確認したこと
- 実際のフォルダー名と説明が一致することを確認しました。
- READMEの前後の説明を読み、矛盾がないことを確認しました。
## 見てほしいこと
初めて作業する人にも、保存場所が伝わるかを確認してください。プログラムの修正なら、再現条件、修正後の動作、実行したテスト、確認できていない範囲なども、必要に応じて添えます。
まだ作業途中の変更を共有したい場合は、DraftのPRを使えます。Draftはそのままではマージできず、レビュー可能な状態になったら「Ready for review」へ切り替えます。GitHub公式：DraftのPull Request
5. コードレビューでは、差分と目的を照らし合わせる
レビューする側は、最初に説明を読み、変更の目的をつかみます。それから「Files changed」でファイルごとの差分を確認します。GitHubでは、行に対応したコメントや、修正案を付けられます。GitHub公式：変更内容のレビュー
この記事のREADME修正なら、次の点が確認対象になります。
- 実際のフォルダー名と説明が一致しているか。
- 原稿以外のファイルの保存先と混同しないか。
- 周囲の文章と矛盾していないか。
- 今回の目的に関係のない変更が入っていないか。
プログラムなら、異常時の動作、入力条件、影響する機能、テストの内容なども確認します。自動チェックの成功と、人が変更の目的や使われ方を確認することは、それぞれ役割があります。
コメントは、気になる箇所と理由を具体的に書くと伝わりやすくなります。たとえば、説明用のコメントなら次のようにできます。
この説明だと、画像もarticlesへ置くように読めそうです。原稿の保存先だとわかるように、「記事原稿」と書くのはどうでしょうか。
修正が必要な指摘なのか、質問なのか、任意の提案なのかも示すと、作成者が対応を判断しやすくなります。人ではなく、変更の内容と理由について話し合いましょう。
6. Comment・Approve・Request changesの違い
GitHubのレビューには、次の3種類の判断があります。
| 判断 | 意味 |
|---|---|
| Comment | コメントを伝える。承認や変更要求の判断は付けない |
| Approve | この変更を承認する |
| Request changes | 取り込む前に変更を求める |
まとめてレビューする場合、行へのコメントを下書きとしてため、最後にレビューを送信します。保留中のレビューコメントは、送信するまで他の人へ伝わりません。書き終えたら、送信まで完了したかを確認しましょう。GitHub公式：Pull Requestレビュー
作成者は、指摘の理由を読み、必要な修正をコミットして同じブランチへpushします。元のPRには、そのブランチへ追加した変更が反映されます。通常、指摘を直すたびに別のPRを作り直す必要はありません。GitHub公式：作成したPRの変更
修正した箇所を伝え、再確認を依頼します。コメントのやり取りを「解決済み」にすることと、レビューの承認を得ることは同じではありません。コメントを閉じる運用も、チームで合わせておきましょう。
7. 承認されたら、条件を確認してマージする
Approveが付いたからといって、必ずすぐマージできるわけではありません。リポジトリには、必要な承認数、指定のレビュー担当、チェックの成功、会話の解決などの条件を設定できます。追加のコミットによって承認の扱いが変わる設定もあります。GitHub公式：保護されたブランチ
最後に、次を確認します。
- 取り込み先と、最新の変更内容が合っているか。
- 必要なレビューと修正が終わっているか。
- 設定されたチェックが成功しているか。
- 競合など、マージを妨げる状態がないか。
- マージ担当者や取り込み方法が、チームのルールに合っているか。
GitHubでは、通常のマージ、Squash、Rebaseなど、リポジトリで許可された方法を選べる場合があります。方法によってコミット履歴の残り方が変わるため、チームの方針に従います。GitHub公式：Pull Requestのマージ
マージ後は、GitHub側の取り込み先が更新されます。手元のmainを更新するには、前回のpullの記事のように、現在の作業状態を確認して取り込みます。
Webサイトの公開や本番環境への反映が始まるかどうかは、接続された処理と運用によります。PRのマージ、手元への取り込み、本番への公開を分けて考えましょう。
→取り込み先・最新差分・レビュー・修正・チェック・競合・チームのルールを確認
→許可された方法とチームの方針に従ってマージ
→GitHub側の取り込み先が更新
→手元のmain：現在の作業状態を確認して取り込む
→Webサイトの公開・本番反映：接続された処理と運用による
8. まとめと理解度確認
Pull Requestは、変更の目的と差分を共有し、レビューを受けてから取り込むための提案です。レビューでは、変更の意図と最終的な内容を確認し、必要なら修正と再確認を行います。
作成者は、相手が判断できる説明と確認結果を用意します。レビューする側は、具体的な箇所と理由を伝えます。最後に条件を確認してマージする、という流れで進めましょう。
自分の言葉で説明してみる
- Pull Requestとgit pullは、同じ操作ですか？
- PRのbaseとcompareは、それぞれ何を指定しますか？
- PRに差分だけでなく、目的と確認結果を書くのはなぜですか？
- レビューのApproveが付けば、必ずすぐマージできますか？
- 指摘された修正を同じブランチへpushすると、元のPRはどうなりますか？
解答例
- 違います。PRは変更の提案、git pullは手元への取得と取り込みのコマンドです。
- baseは取り込み先、compareは変更を提案する側です。
- 確認する人が、変更の理由と、どこまで確かめたかを判断できるようにするためです。
- 必ずではありません。必要な承認数、チェック、競合、権限などの条件も確認します。
- 追加した変更が元のPRへ反映されます。修正内容を伝え、必要な再確認を受けます。
参考資料
- GitHub公式：Pull Requestについて
- GitHub公式：Pull Requestの作成
- GitHub公式：Pull Requestレビュー
- GitHub公式：変更内容のレビュー
- GitHub公式：保護されたブランチ
- GitHub公式：Pull Requestのマージ
資料確認日：2026年10月11日
コメント