プルリクエストの作成とレビュー依頼

**Pull Request（プルリクエスト、PR）**は、「このブランチの変更を main に取り込んでほしい」とチームメンバーにリクエストする仕組みです。PR を使うことで、コードレビューを経てから変更が本番環境に反映されるため、バグの混入を防げます。

チーム開発では PR が開発サイクルの中心です。この記事では PR の作成からマージまでを実際の操作手順で解説します。

対象読者: ブランチとプッシュの操作（git branch / git push）を習得した方

学習時間の目安: 読了 15分 ＋ 実践 20分

前提知識: ブランチとマージ を完了していること

プルリクエストとは

PR はコードレビューのための仕組みです。単に「変更を取り込む」だけでなく、次のような価値があります。

PR の役割	説明
コードレビュー	チームメンバーが変更内容を確認し、バグや改善点を指摘できる
変更の記録	なぜその変更をしたか、どんな議論があったかが GitHub 上に残る
品質ゲート	テストが通らない・レビューが承認されないと main にマージできない
知識共有	レビューを通じてチーム全員がコードを理解できる

1 人開発でも PR を使う理由

1 人でも PR を使う習慣をつけると、以下のメリットがあります。

• 変更の意図が後から分かる（「なぜこの変更をしたのか」がログに残る）
• Files changed タブでセルフレビューができる（バグに気づきやすい）
• GitHub Actions でテストを自動実行できる

---

PR を作成する

前提：作業ブランチを push する

PR を作成するには、まず作業ブランチを GitHub に push します。

git push origin feature/add-search-function

push 後、GitHub のリポジトリページに移動すると、黄色いバナーで「Compare & pull request」ボタンが表示されます。

「Compare & pull request」から作成する

「Compare & pull request」ボタンをクリックして PR 作成ページを開きます。

ブランチの push から時間が経った場合は、「Pull requests」タブ →「New pull request」からも作成できます。

PR の各フィールドの書き方

フィールド	説明	入力例
タイトル	何をしたか 1 行で	feat: ユーザー検索機能を追加
説明	変更内容・理由・テスト方法	テンプレートを使って記入
Reviewers	レビューを依頼する人	チームメンバーを指名
Labels	PR の種類を表すタグ	bug / enhancement / documentation
Assignees	PR の担当者（通常は自分）	自分を設定
Linked Issues	関連する Issue を紐づける	Closes #42（マージで自動クローズ）

説明の書き方テンプレート

## 変更内容
- ユーザー検索機能を追加した
- 検索結果を一覧表示するコンポーネントを追加した

## 変更の理由
Issue #42 のユーザーリクエストに対応するため。

## テスト方法
1. アプリを起動する
2. ヘッダーの検索バーに名前を入力する
3. 検索結果が表示されることを確認する

## 関連 Issue
Closes #42

Closes #番号 と書くと、PR がマージされたとき自動的に Issue がクローズされます。

ドラフト PR（Draft Pull Request）

ドラフト PR は「まだレビュー不要だが早めにフィードバックをもらいたい」ときに使います。

「Create pull request」ボタンの右側にある「▼」をクリック →「Create draft pull request」を選択します。

ドラフト PR は：

• 「Draft」ラベルが表示される
• マージボタンが無効化される
• 作業が完了したら「Ready for review」ボタンで通常 PR に変更できる

実装の方向性について早めに確認したい場合や、作業途中でレビューコメントをもらいたい場合に便利です。

---

PR の画面の見方

PR ページには 4 つのタブがあります。

タブ	内容
Conversation	コメントと議論の一覧。マージボタンもここにある
Commits	このブランチのコミット一覧
Checks	GitHub Actions などの自動テスト結果
Files changed	変更されたファイルの差分

「Files changed」で差分を確認する

「Files changed」タブでは、変更前（赤）と変更後（緑）の差分が確認できます。

• 行の「＋」ボタンをクリックすると、その行にコメントを追加できます
• 複数行を選択してコメントすることもできます

セルフレビューは必ず「Files changed」タブで行いましょう。

---

レビューコメントへの対応

コメントを受けたら修正してコミットする

レビュアーからコメントが来たら、ローカルでコードを修正してコミットします。

# コードを修正する
git add .
git commit -m "fix: レビュー指摘に対応 - バリデーションを追加"
git push origin feature/add-search-function

push すると PR に自動的に新しいコミットが追加されます。レビュアーには変更が通知されます。

対応済みコメントをクローズする

対応が完了したコメントは「Resolve conversation」ボタンをクリックしてクローズします。クローズされたコメントは折り畳まれ、未対応の項目が目立つようになります。

再レビューを依頼する

修正が完了したら、レビュアーに再確認を依頼します。「Reviewers」セクションの右側にある更新アイコン（↺）をクリックすると「Re-request review」ができます。

---

マージの方法

レビュアーから「Approve」をもらったら、PR をマージできます。GitHub では 3 種類のマージ方法が選べます。

マージ方法	特徴	初心者への推奨度
Merge commit	すべてのコミットが保持され、マージコミットが作成される	普通
Squash and merge	ブランチのコミットを 1 つにまとめてマージ	おすすめ
Rebase and merge	マージコミットを作らず直線的な履歴にする	上級者向け

初心者チームには「Squash and merge」が最もおすすめです。 作業中の「WIP」「修正」といった細かいコミットが main の履歴に残らず、変更の意図が 1 つのコミットにまとめられます。

マージ後のブランチ削除

マージ後に「Delete branch」ボタンが表示されます。マージ済みブランチは削除することを推奨します。 不要なブランチが増えると管理が煩雑になります。

---

PR 作成のチェックリスト

PR を出す前に以下を確認しましょう。

- [ ] タイトルが「何をしたか」を 1 行で表している
- [ ] 説明に変更内容・理由・テスト方法が書かれている
- [ ] 「Files changed」で自分でセルフレビューした
- [ ] レビュアーを指定した
- [ ] 関連 Issue を Closes #番号 でリンクした
- [ ] コンフリクトが発生していない
- [ ] （CI がある場合）テストが通っている

---

FAQ

Q. PR にコミットを push すると自動的に更新されますか？

はい。同じブランチに push するだけで PR が自動的に更新されます。新しいコミットが追加されると、レビュアーに通知が送られます。

Q. Draft PR と通常 PR はどう使い分けますか？

実装が完成して「今すぐレビューしてほしい」場合は通常 PR を使います。「まだ作業中だが方針を確認したい」「仕様の認識合わせをしたい」場合は Draft PR を使います。Draft の間はレビュアーにマージを急かすことになりません。

Q. レビュアーがいない（1 人開発の場合）はどうすればよいですか？

1 人でも PR を使う価値はあります。「Files changed」タブでセルフレビューし、説明に変更意図を記録してからマージしましょう。GitHub Actions でテストを自動化していれば、テストが通ったことを確認してからマージできます。

Q. PR の説明は英語で書くべきですか？

チームの共通言語に合わせてください。日本語チームなら日本語で問題ありません。英語・日本語混在チームでは英語が標準になることが多いです。