GitHub Pull Request完全ガイド - レビューとマージのベストプラクティス

はじめに

チーム開発において、コードの品質を維持しながら効率的に変更を統合するには「Pull Request（プルリクエスト）」の活用が欠かせません。Pull Requestは単なるマージの仕組みではなく、コードレビューを通じてチームの知識共有や品質向上を実現する重要なコラボレーション機能です。

本記事では、GitHub Pull Requestの作成から効果的なPR説明文の書き方、コードレビューの進め方、レビューコメントへの対応方法、そしてMerge・Squash・Rebaseの3つのマージ方法の使い分けまでを体系的に解説します。この記事を読み終えると、以下のことができるようになります。

• Pull Requestの作成手順を理解し、適切なPRを作成できる
• 効果的なPR説明文（タイトル・本文）を書ける
• コードレビューを効率的に進められる
• レビューコメントへ適切に対応できる
• Merge・Squash・Rebaseの違いを理解し、状況に応じて選択できる

実行環境と前提条件

本記事の内容は、以下の環境で動作確認を行っています。

前提条件として、以下の知識があることを想定しています。

• コマンドライン操作の基礎知識（cd、ls/dir、mkdir等）
• テキストエディタの基本操作
• Gitの基本コマンド（git init、git add、git commit、git log）の理解
• ブランチ操作（git branch、git switch、git merge）の理解
• GitHubアカウントの作成とリモートリポジトリへのpush経験

Gitのバージョンは以下のコマンドで確認できます。

1

git --version

Pull Requestとは

Pull Requestの基本概念

Pull Request（PR）とは、GitHubなどのホスティングサービスが提供する機能で、ブランチの変更内容をベースブランチに統合する「提案」を行う仕組みです。PRを作成すると、変更内容の差分が可視化され、チームメンバーがレビューやコメントを行えるようになります。

gitGraph
   commit id: "m1"
   branch feature-branch
   commit id: "コミットA"
   commit id: "コミットB"
   commit id: "コミットC" tag: "PR作成"
   checkout main
   merge feature-branch id: "m2" tag: "レビュー承認後マージ"

Pull Requestの主な役割は以下のとおりです。

• 変更内容の可視化: 差分を一覧で確認できる
• コードレビュー: チームメンバーがコードを確認し、フィードバックを提供できる
• 議論の場: 実装方針や設計について議論できる
• 品質ゲート: マージ前に承認を必須にすることで品質を担保できる
• 履歴の記録: なぜその変更が行われたかを後から追跡できる

PRを使ったチーム開発ワークフロー

一般的なPRを使った開発ワークフローは以下のようになります。

1. mainブランチから作業用ブランチを作成
2. ブランチ上で機能開発・バグ修正を行う
3. 変更をリモートリポジトリにpush
4. GitHub上でPull Requestを作成
5. チームメンバーがコードレビューを実施
6. 必要に応じて修正を行い、再度push
7. レビュー承認後、mainブランチにマージ
8. 作業ブランチを削除

Pull Requestの作成手順

ステップ1: 作業ブランチの作成とコミット

まず、mainブランチから作業用のブランチを作成します。

1
2
3
4
5
6

# mainブランチを最新化
git switch main
git pull origin main

# 作業ブランチを作成して切り替え
git switch -c feature/add-login-validation

作業ブランチ上で必要な変更を行い、コミットします。

1
2
3
4
5
6
7
8

# ファイルを編集
# ...

# 変更をステージング
git add src/auth/validator.js

# コミット
git commit -m "feat: ログインフォームにバリデーション機能を追加"

ステップ2: リモートリポジトリへのpush

作業ブランチをリモートリポジトリにpushします。

1

git push origin feature/add-login-validation

実行結果の例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 456 bytes | 456.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote:
remote: Create a pull request for 'feature/add-login-validation' on GitHub by visiting:
remote:      https://github.com/your-org/your-repo/pull/new/feature/add-login-validation
remote:
To github.com:your-org/your-repo.git
 * [new branch]      feature/add-login-validation -> feature/add-login-validation

push完了時に表示されるURLからPRを作成できます。

ステップ3: GitHub上でPull Requestを作成

GitHubのリポジトリページにアクセスすると、pushしたブランチに対して「Compare & pull request」ボタンが表示されます。このボタンをクリックするか、「Pull requests」タブから「New pull request」を選択してPRを作成します。

PR作成画面では、以下の項目を設定します。

効果的なPR説明文の書き方

PRタイトルのベストプラクティス

PRタイトルは、変更内容を一目で理解できるように簡潔かつ具体的に記述します。

良いタイトルの例：

1
2
3
4

feat: ログインフォームにメールアドレスのバリデーションを追加
fix: ユーザー一覧ページで発生する無限ループを修正
refactor: 認証モジュールの責務を分離
docs: API仕様書にエンドポイントの説明を追加

避けるべきタイトルの例：

1
2
3
4

修正しました
Update validator.js
WIP
いろいろ直した

Conventional Commitsの形式（type: description）を採用すると、変更の種類が明確になり、変更履歴の自動生成にも役立ちます。

PR説明文のテンプレート

PR説明文には、以下の情報を含めることを推奨します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

## 概要
このPRで何を実現するのかを簡潔に説明します。

## 変更内容
- 変更点1: 具体的な変更内容
- 変更点2: 具体的な変更内容

## 関連Issue
- Closes #123
- Related to #456

## 動作確認
- [ ] ローカル環境で動作確認済み
- [ ] ユニットテスト追加・更新済み
- [ ] 既存テストがパスすることを確認済み

## スクリーンショット（UI変更がある場合）
変更前と変更後のスクリーンショットを添付します。

## レビューポイント
レビュアーに特に確認してほしい箇所を記載します。

## 注意事項
マージ後に必要な作業や、注意すべき点があれば記載します。

GitHubでは、リポジトリの.github/PULL_REQUEST_TEMPLATE.mdにテンプレートを配置すると、PR作成時に自動的にテンプレートが適用されます。

IssueとPRの連携

PR説明文に特定のキーワードとIssue番号を記載すると、PRがマージされた際に関連Issueを自動的にクローズできます。

1
2
3
4

## 関連Issue
- Closes #123
- Fixes #456
- Resolves #789

使用できるキーワードは以下のとおりです。

• close、closes、closed
• fix、fixes、fixed
• resolve、resolves、resolved

ドラフトPull Requestの活用

ドラフトPRとは

作業途中でフィードバックを得たい場合や、実装方針を共有したい場合は「ドラフトPull Request」を活用します。ドラフトPRは以下の特徴を持ちます。

• マージボタンが無効化される
• CODEOWNERSによる自動レビューリクエストが発生しない
• 「Draft」ラベルが表示され、作業中であることが明示される

ドラフトPRの作成方法

PR作成画面で「Create pull request」ボタンの横にあるドロップダウンから「Create draft pull request」を選択します。

作業が完了したら、PRページの「Ready for review」ボタンをクリックして通常のPRに変換します。これにより、レビュアーへの通知が送信され、正式なレビューを依頼できます。

コードレビューの進め方

レビュアーとしてのコードレビュー

PR画面の「Files changed」タブで変更内容を確認します。特定の行にコメントを追加するには、行番号の左側にある「+」アイコンをクリックします。

コメントには以下の種類があります。

Suggested changesの活用

レビュー中に具体的な修正案がある場合は、Suggested changesを使用すると効果的です。コメント欄のツールバーにある「Suggest changes」アイコンをクリックし、以下の形式で記述します。

1
2
3
4
5
6

```suggestion
const validateEmail = (email) => {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
};
```

PR作成者は、この提案を「Commit suggestion」ボタンで直接適用できます。複数の提案をまとめて適用する「Batch changes」機能も利用可能です。

レビューの送信

レビューが完了したら、「Review changes」ボタンからレビュー結果を送信します。送信時には以下の3つのオプションから選択します。

効果的なレビューコメントの書き方

良いレビューコメントは、問題点の指摘だけでなく、改善案や理由を含めます。

避けるべきコメント例：

1
2

これは間違っています。
なぜこう書いたのですか？

推奨されるコメント例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

この条件分岐では、emailがnullの場合にエラーが発生する可能性があります。
以下のようにnullチェックを追加することを提案します。

`suggestion
if (email && validateEmail(email)) {
  // ...
}
`

理由: フォームの初期状態ではemailがnullになる可能性があり、
その場合validateEmail関数内でundefinedのメソッドを呼び出してしまいます。

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

コメントへの返信と修正

レビューコメントを受け取ったら、以下の手順で対応します。

1. コメントを確認: 指摘内容を理解する
2. 対応方針を決定: 修正する、議論する、対応不要と判断する
3. 修正をコミット: 必要な修正を行い、同じブランチにpush
4. コメントに返信: 対応内容を返信し、「Resolve conversation」でスレッドを解決

1
2
3
4
5
6
7
8
9

# レビューコメントに基づいて修正
# ...

# 修正をコミット
git add src/auth/validator.js
git commit -m "fix: レビュー指摘対応 - nullチェックを追加"

# リモートにpush（同じブランチに追加される）
git push origin feature/add-login-validation

pushすると、PRに新しいコミットが追加され、レビュアーに通知されます。

Re-requestレビュー

修正が完了したら、レビュアーに再レビューを依頼します。PRページの「Reviewers」セクションで、レビュアーのアイコン横にある「Re-request review」ボタンをクリックします。

マージ方法の選択

GitHub Pull Requestでは、3つのマージ方法が提供されています。プロジェクトの運用方針や状況に応じて適切な方法を選択することが重要です。

Create a merge commit（通常のマージ）

すべてのコミットを保持し、マージコミットを作成してベースブランチに統合します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[Create a merge commit]

マージ前:
main:     A --- B --- C
                 \
feature:          D --- E --- F

マージ後:
main:     A --- B --- C ----------- M (マージコミット)
                 \               /
feature:          D --- E --- F

特徴：

• すべてのコミット履歴が保持される
• マージコミットにより、統合ポイントが明確になる
• 誰がいつマージしたかが記録される
• 履歴が複雑になりやすい

使用場面：

• チームの開発履歴を完全に保持したい場合
• 各コミットの文脈が重要な場合
• Git Flowなどの戦略で明示的なマージポイントが必要な場合

Squash and merge（スカッシュマージ）

PRのすべてのコミットを1つのコミットにまとめてベースブランチに統合します。

1
2
3
4
5
6
7
8
9

[Squash and merge]

マージ前:
main:     A --- B --- C
                 \
feature:          D --- E --- F

マージ後:
main:     A --- B --- C --- S (スカッシュされた1コミット)

特徴：

• 複数のコミットが1つにまとまる
• mainブランチの履歴がシンプルになる
• 作業中の細かいコミット（typo修正、WIP等）が非表示になる
• 個々のコミット履歴は失われる

使用場面：

• mainブランチの履歴をクリーンに保ちたい場合
• 作業中の細かいコミットを隠したい場合
• 1つの機能・修正を1コミットとして記録したい場合

注意点：

長期間運用するブランチでSquash mergeを繰り返すと、コンフリクトが発生しやすくなります。これは、元のコミットとスカッシュされたコミットが別物として扱われるためです。

Rebase and merge（リベースマージ）

PRのコミットをベースブランチの先頭にリベースし、マージコミットなしで統合します。

1
2
3
4
5
6
7
8
9

[Rebase and merge]

マージ前:
main:     A --- B --- C
                 \
feature:          D --- E --- F

マージ後:
main:     A --- B --- C --- D' --- E' --- F'

特徴：

• 線形の履歴が維持される
• マージコミットが作成されない
• 各コミットが個別に保持される（コミットハッシュは変更される）
• コンフリクトがある場合は使用できない

使用場面：

• 線形の履歴を維持したい場合
• 各コミットを個別に保持しつつ、履歴をクリーンにしたい場合
• Trunk Based Developmentを採用している場合

3つのマージ方法の比較

リポジトリ設定でのマージ方法制限

リポジトリの管理者は、許可するマージ方法を制限できます。「Settings」→「General」→「Pull Requests」セクションで、以下のオプションを設定できます。

• Allow merge commits
• Allow squash merging
• Allow rebase merging

チームで統一した運用を行う場合は、許可するマージ方法を限定することを推奨します。

Pull Requestマージ後の作業

マージ後のブランチ削除

PRがマージされたら、不要になった作業ブランチを削除します。

GitHub上での削除：

PRがマージされると「Delete branch」ボタンが表示されます。このボタンをクリックしてリモートブランチを削除します。

ローカルブランチの削除：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# mainブランチに切り替え
git switch main

# リモートの最新を取得
git pull origin main

# ローカルブランチを削除
git branch -d feature/add-login-validation

# リモート追跡ブランチを削除
git fetch --prune

実行結果の例：

1

Deleted branch feature/add-login-validation (was 1a2b3c4).

自動ブランチ削除の設定

リポジトリ設定で「Automatically delete head branches」を有効にすると、PRマージ時にブランチが自動削除されます。「Settings」→「General」→「Pull Requests」セクションで設定できます。

Pull Requestのベストプラクティス

PRのサイズを適切に保つ

大きすぎるPRはレビューが困難になり、品質低下の原因となります。以下の目安を参考にしてください。

• 変更ファイル数: 10ファイル以下が望ましい
• 変更行数: 400行以下が望ましい
• レビュー時間: 30分以内でレビュー可能なサイズ

大きな機能は複数のPRに分割し、段階的にマージすることを推奨します。

セルフレビューの実施

PRを作成する前に、自分自身でコードをレビューします。「Files changed」タブで差分を確認し、以下の点をチェックします。

• 意図しない変更が含まれていないか
• デバッグコードが残っていないか
• コメントやドキュメントが適切か
• テストが追加・更新されているか

CIチェックの確認

PRを作成すると、設定されているCI（継続的インテグレーション）が自動実行されます。「Checks」タブでテストやビルドの結果を確認し、すべてのチェックがパスしてからレビューを依頼します。

コンフリクトの早期解消

PRがベースブランチとコンフリクトしている場合は、早めに解消します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# mainブランチの最新を取得
git switch main
git pull origin main

# 作業ブランチに切り替え
git switch feature/add-login-validation

# mainブランチをマージしてコンフリクト解消
git merge main

# コンフリクトを解消後、コミット
git add .
git commit -m "merge: mainブランチとのコンフリクトを解消"

# リモートにpush
git push origin feature/add-login-validation

または、rebaseを使用する方法もあります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# mainブランチの最新を取得
git switch main
git pull origin main

# 作業ブランチでリベース
git switch feature/add-login-validation
git rebase main

# コンフリクトを解消後、続行
git rebase --continue

# 強制push（履歴が変更されるため）
git push --force-with-lease origin feature/add-login-validation

トラブルシューティング

PRがマージできない場合

PRがマージできない主な原因と対処法を示します。

誤ってマージした場合

誤ってPRをマージした場合は、「Revert」ボタンで取り消しPRを作成できます。PRページの下部にある「Revert」ボタンをクリックすると、マージを打ち消す新しいPRが自動作成されます。

まとめ

GitHub Pull Requestは、チーム開発における品質向上と知識共有の要となる機能です。本記事で解説した内容を振り返ります。

• PR作成: ブランチを作成し、変更をpushしてPRを作成する
• 説明文: 具体的なタイトルと、テンプレートに沿った説明文を記述する
• レビュー: Suggested changesを活用し、建設的なフィードバックを行う
• 対応: レビューコメントに対応し、スレッドを解決して再レビューを依頼する
• マージ: Merge・Squash・Rebaseの特徴を理解し、状況に応じて選択する

これらのプラクティスを実践することで、チーム全体のコード品質と開発効率を向上させることができます。

参考リンク

• GitHub公式ドキュメント - pull requestsについて
• GitHub公式ドキュメント - プルリクエストのレビューについて
• GitHub公式ドキュメント - プルリクエストのマージについて
• GitHub公式ドキュメント - プルリクエストの作成
• GitHub Skills - Review pull requests
• Conventional Commits