はじめに
業務で Git と GitHub を使い始めた初心者です。
前回の記事では、git add・git commit・git push をしたときに、ファイルがどこに行くのかを整理しました。最後に「次は Pull Request とマージまわりを整理したい」と書いたので、その続きです。
Pull Request（以下 PR）は、「自分のブランチの変更を、チームの共有ブランチに入れてください」というお願いです。仕組みは分かったつもりでいたのですが、実際に GitHub の画面で PR を出してみると、見慣れない表示が次々に出てきて、そのたびに手が止まりました。この1か月で戸惑ったものを、出てきた順に書き残しておきます。
初心者が理解した順に書いています。画面の文言は、執筆時点（2026年10月）の英語表示のものです。GitHub の画面は変わることがあるので、正確なところは公式ドキュメントを参照してください。
この記事で使う例
説明を通して、次の4つのブランチを使います。
| ブランチ | 役割 |
|---|---|
main |
本番用。作業ブランチを直接入れることはない |
develop |
チームの共有ブランチ。作業ブランチの PR はここに出す |
feature/sample |
自分の作業ブランチ（1本目） |
feature/sample-2 |
自分の作業ブランチ（2本目。7. で登場） |
前回の記事では入れる先を main として書きましたが、私のチームでは、作業ブランチを入れる先は main ではなく開発用の共有ブランチでした。この記事ではそれを develop と呼びます。
1. 入れる先の base: main
PR の作成画面の上のほうに、こういう行があります。
base: main ← compare: feature/sample
| 項目 | 意味 | この例で選ぶもの |
|---|---|---|
| base | 変更を入れる先 | develop |
| compare | 変更を持ってくる元（自分のブランチ） | feature/sample |
矢印の向きどおり、「feature/sample の変更を、base に入れたい」という意味です。
ここで私は、base が main のまま PR を出してしまいました。GitHub は、リポジトリの既定のブランチ（多くは main）を base の初期値にするそうです。入れる先が main ではないチームでは、作成画面で毎回変える必要がありました。
出したあとでも base は変えられる
焦りましたが、マージする前なら、PR を作り直さずに直せます。
- PR のページで、タイトルの右にある Edit を押す
- タイトルの下に
base: mainの選択欄が出るので、押してdevelopを選ぶ - 確認が出るので Change base を押す
- Files changed タブを開き、自分が変えたファイルだけが並んでいるかを確かめる
base を変えても、PR の番号・説明文・コメントはそのまま残ります。
すでにマージしてしまった場合は、この方法では直せません。 共有のブランチを元に戻す作業になるので、ひとりで直そうとせず、先輩に相談してください。
作った直後の Checking for the ability to merge automatically...
PR を作った直後に、ページの下のほうにこう出ることがあります。
Checking for the ability to merge automatically...
Hang in there while we check the branch's status.
警告のように見えますが、GitHub が「このまま問題なくマージできるか」を調べている最中の表示です。少し待つと消えます。
2. 作成ボタンの ▼ にある Create draft pull request
PR の説明文は長くなるので、「Create pull request を押したら、もう直せないのでは？」と心配でした。一時保存のボタンも見当たりません。
結論から書くと、タイトルも説明文も、作ったあとに何度でも書き換えられます。
| 直すもの | 場所 |
|---|---|
| タイトル | タイトルの右の Edit |
| 説明文 | 説明文の右上の … → Edit |
一時保存のボタンはありませんが、近いものとして Draft（下書き）の PR があります。Create pull request ボタンの右端の ▼ を押すと選べます。
┌──────────────────────────┬───┐
│ Create pull request │ ▼ │ ← ここを押す
└──────────────────────────┴───┘
↓
・Create pull request … 普通の PR
・Create draft pull request … 下書きの PR
下書きの PR は、PR としては作られますが「まだ準備中」の印が付き、マージできません。準備ができたら、PR のページの一番下にある Ready for review を押すと、普通の PR になります。
┌───────────────────────────────────────────────────┐
│ This pull request is still a work in progress │
│ Draft pull requests cannot be merged. │
│ [ Ready for review ]│
└───────────────────────────────────────────────────┘
普通の PR を下書きに戻すこともできます（右側の欄にある Convert to draft）。
便利そうなので使ってみたのですが、これが次の勘違いにつながりました。
3. タイトルの下の Draft
PR を何本か出しているうちに、こう思うようになりました。
「ほかのメンバーは PR を出したら自分ですぐマージしているのに、自分だけ、誰かに承認してもらわないとマージできない」
PR のページを開いても、マージのボタンが見当たらないのです。権限の設定が自分だけ違うのかと思い、調べてもらいました。
結果は、権限も設定も、ほかのメンバーと同じでした。違ったのは、自分の PR が、作った時点で毎回 Draft（下書き）になっていたことです。
- で書いたとおり、Draft の PR にはマージのボタンが出ません。これまでは先輩たちが Ready for review を押してくれていたので、「承認してもらうとマージできるようになる」ように見えていたのでした。
| 思っていたこと | 実際 | |
|---|---|---|
| マージのボタンが出ない理由 | 承認をもらっていないから | Draft のままだったから |
| 先輩がしてくれていたこと | 承認 | Ready for review を押す |
見分け方は簡単で、PR のタイトルのすぐ下にある印を見ます。
| 印 | 状態 |
|---|---|
| Draft | 下書き。マージできない |
| Open | 普通の PR。チームの決まり（承認が要るかなど）を満たせばマージできる |
それからは、PR を作るときに押すボタンが下書きのほうになっていないかを確かめるようにしました。
4. 自分の返信に付いた Pending
先輩からのレビューで、コードの行ごとにコメントをもらいました。それぞれに返信したところ、自分の返信にこう出ていました。
my-account started a review
Pending
「started a review？ 自分で自分の PR をレビューしたことになった？」と焦りましたが、違いました。返信がまだ送られていない（下書きのまま） という意味でした。
Files changed タブでコメントに返信するとき、ボタンが2つあります。
| ボタン | 動き |
|---|---|
| Add single comment | その1件をすぐに送る |
| Start a review | 下書きとしてためておき、あとでまとめて送る |
私は Start a review を押していたので、返信がたまったままになっていました。この状態の返信は自分にしか見えず、相手にはまだ届いていません。
送るには、次のようにします。
- Files changed タブの右上にある Finish your review（表示によっては Review changes）を押す
- Comment を選ぶ
- Submit review を押す
送ったあと、Pending の表示が消えていれば届いています。
「review」という名前ですが、承認とは関係ありません。そもそも PR を出した本人は、自分の PR を承認（Approve）できません。
すぐに送りたいときは、Add single comment を押すか、Conversation タブのコメントの下にある返信欄から送れば、下書きにはなりません。
5. 先輩のコメントに付いた Outdated
指摘を受けてコードを直し、push したら、先輩のコメントに Outdated という印が付きました。何かまずいことをしたのかと思いましたが、これも問題ではありませんでした。
outdated は英語で「古くなった」という意味です。コメントが付いていた行が、そのあとのコミットで書き換えられたという印でした。指摘を受けて直せば、ふつうは付きます。
紛らわしかったのが、Resolved との違いです。
| 印 | 誰が付けるか | 意味 |
|---|---|---|
| Outdated | GitHub が自動で付ける | コメントした行が書き換えられた |
| Resolved | 人が Resolve conversation を押す | そのやり取りが終わった |
Outdated は「解決済み」ではありません。 返信もできます。ただ、Files changed タブでは最新のコードにその行が無いため、折りたたまれて見つけにくくなります。返信するときは Conversation タブから探すと見つけやすかったです。
6. 一番下にだけある Add a comment
1回目のレビューでは、コメント1件ずつに返信の欄があったのに、2回目のレビューでは一番下の Add a comment しか見当たりませんでした。
違いは、先輩のコメントがどこに付いていたかでした。
| コメントの種類 | どこに付くか | 返し方 |
|---|---|---|
| 行へのコメント | コードの特定の行 | そのコメントの下の返信欄 |
| PR 全体へのコメント | PR そのもの | 一番下の Add a comment |
2回目のレビューは「修正ありがとうございます！…」で始まる、PR 全体へのまとまったコメント1件でした。行には付いていないので、行ごとの返信欄が無いのは正常でした。返事も、一番下の Add a comment にまとめて書けば大丈夫です。
7. 作業ブランチを入れる先にした base: feature/sample
feature/sample の PR（以下 PR①）がレビュー待ちのあいだに、続きの作業を頼まれました。ところが、続きの作業は PR① で直したのと同じ場所を、さらに書き換えるものでした。
develop から新しくブランチを作ると、develop にはまだ PR① の変更が入っていないので、PR① より前の状態を書き換えることになります。そのまま進めると、PR① がマージされたときに同じ場所でぶつかります（コンフリクト）。
そこで教わったのが、PR① のブランチの上に、続きのブランチを作るやり方です。
develop ───●─────────────────────────────────────
\
feature/sample ───●───● ← PR①（base: develop）レビュー待ち
\
feature/sample-2 ───●───● ← PR②（base: feature/sample）
# PR① のブランチに移ってから、そこから続きのブランチを作る
git switch feature/sample
git switch -c feature/sample-2
PR② を出すときは、base を develop ではなく feature/sample にします。こうすると、PR② の Files changed には続きの作業の分だけが出るので、レビューする人が PR① の変更と混ざらずに見られます。
PR① のレビューで直しが入っても、その直しを PR② のブランチに取り込めば大丈夫でした。
# PR② のブランチに移ってから、PR① のブランチの直しを取り込む
git switch feature/sample-2
git merge feature/sample
PR① がマージされたら、PR② の base を付け替える
PR① が develop にマージされたら、1. と同じ手順（Edit → base を選ぶ → Change base）で、PR② の base を feature/sample から develop に変えます。
| 時点 | PR② の base | PR② の Files changed に出るもの |
|---|---|---|
| PR① がレビュー待ち | feature/sample |
続きの作業の分だけ |
| PR① がマージされた後 |
develop に付け替える |
続きの作業の分だけ（PR① の分は、もう develop に入っている） |
base を develop に変えるのは、PR① がマージされたのを確かめてからにします。先に変えると、まだ develop に入っていない PR① の変更まで、PR② の差分に混ざって見えてしまいます。
base を変えるのは「ブランチの親を変える」のとは別
「base を後から変えられる」と聞いて、最初は「ブランチを作った元（親）を変えることかな？」と思いましたが、別物でした。
| 何を変えるか | コミットへの影響 | |
|---|---|---|
| PR の base を変える | その PR をどこと比べて、どこに入れるかという PR の設定 | 何も起きない |
| ブランチの親を変える | ブランチを、別のブランチの先から作り直す（git rebase という操作） |
コミットが作り直される |
今回やったのは、上の「PR の base を変える」だけです。
まとめ
| 戸惑った表示・場面 | 正体 | やること |
|---|---|---|
base: main |
入れる先が main になっている |
Edit → base を選ぶ → Change base |
Checking for the ability to merge automatically... |
マージできるかを調べている最中 | 少し待つ |
| マージのボタンが無い | PR が Draft のまま | Ready for review を押す |
started a review / Pending
|
返信がまだ送られていない | Finish your review → Comment → Submit review |
| Outdated | コメントした行が書き換えられた | 何もしなくてよい（返信はできる） |
| 返信の欄が無い | PR 全体へのコメントだった | 一番下の Add a comment に書く |
| 前の PR のマージ前に続きを始めたい | 前の PR のブランチの上に作る | base を前の PR のブランチにし、マージ後に付け替える |
今日から変えたこと
- PR を作るとき、base が入れる先のブランチになっているかを必ず見る
- PR を作ったら、タイトルの下の印が Draft か Open かを見る
- 作ったら Files changed タブで、自分が変えたファイルだけが並んでいるか確かめる
- レビューに返信したら、Pending が残っていないかを見る
おわりに
どれも、分かってしまえば「表示のとおり」でした。ただ、英語の短い表示だけでは、初心者には「何かまずいことをした」ように見えてしまいます。特に Draft の件は、2週間ほど「自分だけ権限が違う」と思い込んでいました。
同じように画面の前で手が止まった方の参考になれば嬉しいです。間違いや、もっと良いやり方があればコメントで教えていただけると嬉しいです。
参考
- pull request の作成 - GitHub Docs
- プルリクエストのベースブランチの変更 - GitHub Docs
- プルリクエストのステージの変更 - GitHub Docs — Draft と Ready for review
- プルリクエストへのコメント - GitHub Docs
- プルリクエストで提案された変更をレビューする - GitHub Docs — 送る前のコメントが「保留中」になる件
- 【初心者の備忘録】git add したファイルは、どこに行ったのか — 前回の記事