← 社会保険労務士法人ミライズ労務コンサルティング トップページ
DEVELOPMENT WORKFLOW GUIDE

GitHub Pull Request 完全ガイド

「本流を汚さずに変更を提案し、レビューを経て合流させる」— プロの開発現場の中核となる仕組みを、コマンドから画面操作まで一気通貫で解説します。

main(本流) feature/○○(作業用ブランチ) マージ Pull Request 分岐して作業 レビューOK後に合流
CHAPTER 01

Pull Request とは何か

Pull Request(以下 PR)を一言でいえば、「私の変更を本流(main)に取り込んで(Pull して)ください、という正式なリクエスト」です。ポイントは、mainブランチを直接書き換えるのではなく、必ず「提案 → レビュー → 承認 → 合流」の関門を通すことにあります。

PRを使わない開発
全員がmainに直接コミット。誰がいつ何を変えたか追いにくく、壊れたコードが即座に本番系統に混入する。レビューの記録も残らない。
PRを使う開発
変更は必ずブランチ上で行い、PRでレビューを受けてからmainに合流。指摘と修正の履歴がすべて残り、mainは常に「動く状態」が保たれる。
社労士業務でのアナロジー: mainブランチ=届出済みの就業規則の「原本」、ブランチ=改定案のドラフト、PR=改定案の回覧・決裁、マージ=原本への正式反映。原本にいきなり赤を入れないのと同じ発想です。
① ブランチ作成作業場所を分ける
② 変更&コミット作業を記録
③ プッシュGitHubへ送信
④ PR作成レビュー依頼
⑤ レビュー対応指摘→修正
⑥ マージmainへ合流
CHAPTER 02

PRの出し方 — 6ステップ

1

作業用ブランチを作るターミナル

まずmainを最新にしてから、作業用のブランチを切ります。ブランチ名は feature/内容fix/内容 のように目的がわかる名前にするのが慣例です。

Terminal
# mainブランチを最新の状態にする
git checkout main
git pull origin main

# 作業用ブランチを作成して移動(-b は「作成して切替」)
git checkout -b feature/login-form
Switched to a new branch 'feature/login-form'
2

変更してコミットするターミナル

ファイルを編集したら、変更を「コミット」として記録します。コミットは意味のある単位で小さく刻むのがレビューしやすさのコツです。

Terminal
# 変更されたファイルを確認
git status

# 変更をステージング(コミット対象に載せる)
git add src/components/LoginForm.tsx

# メッセージ付きでコミット
git commit -m "ログインフォームにバリデーションを追加"
コミットメッセージの型: 「何をしたか」を1行で。チームによっては feat:(機能追加)、fix:(修正)、docs:(文書)などの接頭辞ルール(Conventional Commits)を使います。
3

GitHubへプッシュするターミナル

手元(ローカル)のブランチをGitHub(リモート)へ送信します。初回プッシュ時は -u を付けてリモートと紐付けます。

Terminal
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が親切に表示されます。これをクリックするのが最短ルートです。

4

PRを作成するGitHub画面

GitHubのリポジトリを開くと、プッシュしたブランチについて黄色い帯で 「Compare & pull request」 ボタンが表示されます。これを押すとPR作成画面へ。

作成画面で入力するのは主に3つです。

項目書くこと
タイトル変更内容の要約。「ログインフォームのバリデーション追加」など、一覧で見て意味がわかるように。
説明(Description)「なぜこの変更が必要か」「何をどう変えたか」「確認方法」。スクショを貼るのも有効。多くのチームはテンプレートを用意しています。
Reviewers右側のサイドバーでレビューしてほしい人を指定。指定された人に通知が飛びます。

ベースブランチが base: main ← compare: feature/login-form になっていること(=mainに対してこのブランチを取り込む方向)を確認し、「Create pull request」を押せば完了です。

5

レビューを受けて修正するGitHub画面ターミナル

レビュアーはPRの 「Files changed」 タブで差分(削除行=赤、追加行=緑)を確認し、気になる行にカーソルを合わせて青い+ボタンを押すと、その行に直接コメントを付けられます。

Open ログインフォームにバリデーションを追加 #42
const handleSubmit = () => {
- login(email, password);
+ if (email && password) {
+ login(email, password);
+ }
hattori-mirise がこの行にコメント
空チェックだけだとメール形式の誤入力が通ってしまいます。正規表現での形式チェックも入れませんか?
hokama-mirise(作成者)が返信
確かに。バリデーション関数を切り出して対応します 👍

レビュアーは最後に「Review changes」から3種類の判定を出します。

判定意味
Approve承認。マージしてOK。
Request changes修正要求。対応するまでマージ不可(設定による)。
Comment判定なしのコメントのみ。質問や軽い提案に。

修正を求められたら、同じブランチ上で修正コミットを積んでプッシュするだけ。PRに自動で反映されます。新しいPRを作り直す必要はありません。

Terminal
# 指摘を修正したら、同じブランチにコミット&プッシュ
git add src/utils/validation.ts
git commit -m "メール形式のバリデーションを追加(レビュー指摘対応)"
git push

対応が済んだ指摘は、コメントスレッドの「Resolve conversation」を押して解決済みにします。全スレッドの解消がマージ条件になっているチームが多いです。

6

マージして後片付けGitHub画面

Approveが揃ったら、PR画面下部の緑の 「Merge pull request」 ボタンでmainへ合流させます。マージ方式は3種類から選べます。

方式特徴
Merge commitブランチの履歴をそのまま残して合流。履歴が詳細に残るが枝分かれが増える。
Squash and mergeブランチ内の複数コミットを1つに圧縮して合流。mainの履歴が「1PR=1コミット」で読みやすくなる。小規模チームの定番。
Rebase and mergeコミットをmainの先端に付け替えて一直線の履歴にする。上級者向け。

マージ後は「Delete branch」ボタンで役目を終えたブランチを削除し、手元も掃除しておきます。

Terminal
git checkout main
git pull origin main          # マージ結果を手元に反映
git branch -d feature/login-form  # ローカルのブランチを削除
CHAPTER 03

ターミナルだけで完結する — gh CLI と Claude Code

GitHub公式のコマンドラインツール gh CLI を使うと、ブラウザを開かずにPRの作成からマージまで完結できます。Claude Codeも内部的にこの流れを使うため、仕組みを知っておくと指示の精度が上がります。

Terminal — gh CLI
# 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
Claude Codeでの実践: 「この変更をブランチを切ってコミットし、PRを作成して。説明文には変更理由と確認手順を書いて」と指示するだけで、ステップ1〜4をClaude Codeが代行します。手書きレビューPDFを渡して「指摘を1件ずつIssue化 → 各Issueをブランチで修正 → PRを作成」という一連のフローも組めます。人間のチームでは複数人で回すレビューサイクルを、一人+AIで再現できる形です。
CHAPTER 04

よくあるつまずきと用語ミニ辞典

つまずきポイント

症状原因と対処
mainに直接コミットしてしまったコミット前なら git checkout -b feature/○○ でそのままブランチを切ればOK(変更は持ち越される)。コミット後でも git branch feature/○○ → mainを戻せば回収可能。
PR作成時に「Conflict」と表示される自分のブランチとmainが同じ箇所を変更している状態。git merge main をブランチ上で実行し、競合箇所を手で解消してからプッシュ。
PRが巨大になりレビューされない1PRの目安は変更200〜400行以内。大きくなりそうなら機能を分割して複数PRに。「小さく出す」が最重要マナー。
レビュー修正でPRを作り直した不要。同じブランチにコミットを積めばPRに自動反映される。

用語ミニ辞典

用語意味
originGitHub上のリモートリポジトリの標準的な呼び名。
base / comparebase=取り込み先(通常main)、compare=取り込みたい自分のブランチ。
Draft PR「まだ作業中だが方向性を早めに見てほしい」ときの下書きPR。マージ不可の状態で議論できる。
CI(自動チェック)PR作成時に自動実行されるテスト・Lint。GitHub Actionsが代表格。緑のチェックが揃わないとマージ不可にする設定が一般的。
Branch protectionmainへの直接プッシュを禁止し、「PR経由+Approve必須」を強制する設定。チーム開発ではほぼ必須。
LGTM"Looks Good To Me"。レビュー承認時の定番の一言。