GitHub

Pull Request(プルリク)の使い方

Pull Request(プルリク)の作成からレビュー、マージまでの一連の流れを解説

Pull Request(プルリク)の使い方 eyecatch

Pull Request とは

Pull Request(PR、プルリク)は「自分の変更をレビューしてからマージしてほしい」というリクエストです。

GitHub 上でブランチ間の差分を確認し、コードレビューを経て統合します。

チーム開発では main ブランチへの直接プッシュを禁止し、必ず PR 経由でマージするのが一般的です。

バグ報告や機能要望の起点となる Issue の使い方 と組み合わせると、「なぜこの変更が必要か」の経緯を追いやすくなります。

PR の作成手順

  1. フィーチャーブランチで作業してプッシュ

    git switch -c feature/xxx で新しいブランチを作り、作業後に git push -u origin feature/xxx でリモートに送ります。

  2. GitHub 上で「Compare & pull request」をクリック

    プッシュ直後に GitHub のリポジトリページ上部に表示されるバナーから作成できます。

  3. タイトルと説明を記入

    タイトルは変更内容を簡潔に。説明には「なぜこの変更が必要か」「どうテストしたか」を書くとレビューが円滑になります。

  4. レビュアーを指定して作成

    サイドバーからレビュアー、ラベル、マイルストーンなどを指定して Create pull request をクリックします。gh pr create を使えばターミナルから直接作成も可能です。

bash
# ブランチを作成して作業
git switch -c feature/add-login
# ... 変更を加えてコミット ...
git push -u origin feature/add-login

# gh CLI で PR を作成
gh pr create --title "ログイン機能を追加" --body "## 概要\nログインフォームとバリデーションを実装"

# ドラフト PR として作成(WIP)
gh pr create --draft --title "WIP: ログイン機能"

コードレビューの流れ

レビュアーは PR の「Files changed」タブで差分を確認し、行単位でコメントできます。

指摘を受けたら同じブランチに追加コミットしてプッシュするだけで PR に反映されます。

全員が Approve したらマージ可能になります。

「Request changes」は修正が必要な場合、「Comment」は参考意見の場合に使います。

bash
# レビュー指摘を受けて修正
git add .
git commit -m "fix: レビュー指摘を修正"
git push

# gh CLI でレビュー状態を確認
gh pr status
gh pr checks

マージ戦略

  • Create a merge commit

    全コミットを保持したままマージコミットを作成します。ブランチの履歴がそのまま残るため、経緯を後から追いやすいのが利点です。

  • Squash and merge

    PR 内の全コミットを 1 つにまとめて main に統合します。履歴がすっきりするため多くのチームで採用されています。

  • Rebase and merge

    コミットを main にリベースして直線的な履歴を作ります。マージコミットなしで履歴を直線に保ちたい場合に使います。

チームの方針に合わせて選びましょう。

迷ったら Squash and merge が扱いやすい選択肢です。

bash
# gh CLI でマージ
gh pr merge --squash
gh pr merge --merge
gh pr merge --rebase

# マージ後にローカルを更新
git switch main
git pull
git branch -d feature/add-login

関連コマンド