「本流を汚さずに変更を提案し、レビューを経て合流させる」— プロの開発現場の中核となる仕組みを、コマンドから画面操作まで一気通貫で解説します。
Pull Request(以下 PR)を一言でいえば、「私の変更を本流(main)に取り込んで(Pull して)ください、という正式なリクエスト」です。ポイントは、mainブランチを直接書き換えるのではなく、必ず「提案 → レビュー → 承認 → 合流」の関門を通すことにあります。
まずmainを最新にしてから、作業用のブランチを切ります。ブランチ名は feature/内容 や fix/内容 のように目的がわかる名前にするのが慣例です。
# mainブランチを最新の状態にする git checkout main git pull origin main # 作業用ブランチを作成して移動(-b は「作成して切替」) git checkout -b feature/login-form Switched to a new branch 'feature/login-form'
ファイルを編集したら、変更を「コミット」として記録します。コミットは意味のある単位で小さく刻むのがレビューしやすさのコツです。
# 変更されたファイルを確認 git status # 変更をステージング(コミット対象に載せる) git add src/components/LoginForm.tsx # メッセージ付きでコミット git commit -m "ログインフォームにバリデーションを追加"
手元(ローカル)のブランチをGitHub(リモート)へ送信します。初回プッシュ時は -u を付けてリモートと紐付けます。
git push -u origin feature/login-form ... remote: Create a pull request for 'feature/login-form' on GitHub by visiting: remote: https://github.com/mirise/app/pull/new/feature/login-form
プッシュ直後の出力に、PR作成ページへのURLが親切に表示されます。これをクリックするのが最短ルートです。
GitHubのリポジトリを開くと、プッシュしたブランチについて黄色い帯で 「Compare & pull request」 ボタンが表示されます。これを押すとPR作成画面へ。
作成画面で入力するのは主に3つです。
| 項目 | 書くこと |
|---|---|
| タイトル | 変更内容の要約。「ログインフォームのバリデーション追加」など、一覧で見て意味がわかるように。 |
| 説明(Description) | 「なぜこの変更が必要か」「何をどう変えたか」「確認方法」。スクショを貼るのも有効。多くのチームはテンプレートを用意しています。 |
| Reviewers | 右側のサイドバーでレビューしてほしい人を指定。指定された人に通知が飛びます。 |
ベースブランチが base: main ← compare: feature/login-form になっていること(=mainに対してこのブランチを取り込む方向)を確認し、「Create pull request」を押せば完了です。
レビュアーはPRの 「Files changed」 タブで差分(削除行=赤、追加行=緑)を確認し、気になる行にカーソルを合わせて青い+ボタンを押すと、その行に直接コメントを付けられます。
レビュアーは最後に「Review changes」から3種類の判定を出します。
| 判定 | 意味 |
|---|---|
| Approve | 承認。マージしてOK。 |
| Request changes | 修正要求。対応するまでマージ不可(設定による)。 |
| Comment | 判定なしのコメントのみ。質問や軽い提案に。 |
修正を求められたら、同じブランチ上で修正コミットを積んでプッシュするだけ。PRに自動で反映されます。新しいPRを作り直す必要はありません。
# 指摘を修正したら、同じブランチにコミット&プッシュ git add src/utils/validation.ts git commit -m "メール形式のバリデーションを追加(レビュー指摘対応)" git push
対応が済んだ指摘は、コメントスレッドの「Resolve conversation」を押して解決済みにします。全スレッドの解消がマージ条件になっているチームが多いです。
Approveが揃ったら、PR画面下部の緑の 「Merge pull request」 ボタンでmainへ合流させます。マージ方式は3種類から選べます。
| 方式 | 特徴 |
|---|---|
| Merge commit | ブランチの履歴をそのまま残して合流。履歴が詳細に残るが枝分かれが増える。 |
| Squash and merge | ブランチ内の複数コミットを1つに圧縮して合流。mainの履歴が「1PR=1コミット」で読みやすくなる。小規模チームの定番。 |
| Rebase and merge | コミットをmainの先端に付け替えて一直線の履歴にする。上級者向け。 |
マージ後は「Delete branch」ボタンで役目を終えたブランチを削除し、手元も掃除しておきます。
git checkout main git pull origin main # マージ結果を手元に反映 git branch -d feature/login-form # ローカルのブランチを削除
GitHub公式のコマンドラインツール gh CLI を使うと、ブラウザを開かずにPRの作成からマージまで完結できます。Claude Codeも内部的にこの流れを使うため、仕組みを知っておくと指示の精度が上がります。
# PRを作成(タイトルと説明を対話式 or オプションで指定) gh pr create --title "ログインフォームにバリデーション追加" --body "空入力と形式エラーを防止" # 自分に来ているPR一覧を確認 gh pr list # PRの差分をターミナルで確認 gh pr diff 42 # 承認済みPRをSquashでマージし、ブランチも削除 gh pr merge 42 --squash --delete-branch
| 症状 | 原因と対処 |
|---|---|
| mainに直接コミットしてしまった | コミット前なら git checkout -b feature/○○ でそのままブランチを切ればOK(変更は持ち越される)。コミット後でも git branch feature/○○ → mainを戻せば回収可能。 |
| PR作成時に「Conflict」と表示される | 自分のブランチとmainが同じ箇所を変更している状態。git merge main をブランチ上で実行し、競合箇所を手で解消してからプッシュ。 |
| PRが巨大になりレビューされない | 1PRの目安は変更200〜400行以内。大きくなりそうなら機能を分割して複数PRに。「小さく出す」が最重要マナー。 |
| レビュー修正でPRを作り直した | 不要。同じブランチにコミットを積めばPRに自動反映される。 |
| 用語 | 意味 |
|---|---|
| origin | GitHub上のリモートリポジトリの標準的な呼び名。 |
| base / compare | base=取り込み先(通常main)、compare=取り込みたい自分のブランチ。 |
| Draft PR | 「まだ作業中だが方向性を早めに見てほしい」ときの下書きPR。マージ不可の状態で議論できる。 |
| CI(自動チェック) | PR作成時に自動実行されるテスト・Lint。GitHub Actionsが代表格。緑のチェックが揃わないとマージ不可にする設定が一般的。 |
| Branch protection | mainへの直接プッシュを禁止し、「PR経由+Approve必須」を強制する設定。チーム開発ではほぼ必須。 |
| LGTM | "Looks Good To Me"。レビュー承認時の定番の一言。 |