Skip to main content

プルリクエストとコードレビュー

この章で得られるスキル：

  • ✅ プルリクエスト（PR）の意義を説明できる
  • ✅ GitHub上でPRを作成できる
  • ✅ PRの説明文を適切に書ける
  • ✅ コードレビューでコメント・承認・修正依頼ができる
  • ✅ PRをマージし、ローカルを最新状態に同期できる

Step 0: まず体験してみよう​

シナリオ：mainに直接pushしたらバグが入った​

ある日、Aさんがmainブランチに直接pushした。 ところが、そのコードにはバグが混入していた。

チームメンバーが全員pullした後にバグに気づき、全員の開発が止まってしまった。

もし、pushする前に誰かがコードを確認していたら？ → バグに気づけたはずである。

重要

mainブランチに直接pushすると、バグが入ったときの影響範囲が大きい。 変更をmainに取り込む前に、チームメンバーに確認してもらう仕組みが必要である。

→ プルリクエスト（Pull Request） を使えば、マージ前にコードレビューを受けられる。 この章では、PRの作成からレビュー、マージまでの流れを学ぶ。

Step 1: プルリクエスト（PR）とは​

PRの基本的な流れ​

プルリクエスト（Pull Request、通称PR） とは、featureブランチの変更をmainに取り込んでほしいという 「依頼」 である。

PRを作成すると、チームメンバーが変更内容を確認（コードレビュー）し、問題がなければmainにマージする。

PRを使うメリット​

メリット説明
バグの早期発見マージ前にチームがコードを確認するため、バグが本番に混入しにくい
知識の共有他の人のコードを読むことで、チーム全体のスキルが向上する
変更の記録「なぜこの変更をしたか」がPRの説明文として残る
品質の向上「人に見せる」意識がコードの品質を上げる
PRは開発現場の必須プロセス

実務では、mainに直接pushすることは禁止されていることがほとんどである。 必ずPRを通してコードレビューを受けるのが、チーム開発の基本ルールである。

Step 2: PRの作成手順​

前提：featureブランチをpush済みであること​

PRを作成する前に、featureブランチをGitHubにpushしておく必要がある。

# featureブランチで開発・コミット
git switch -c feature/divide
# Calculator.java に割り算メソッドを追加
git add Calculator.java
git commit -m "割り算メソッドを追加"

# GitHubにpush
git push -u origin feature/divide

GitHub上でのPR作成​

  1. GitHubのリポジトリページを開く
  2. 「Compare & pull request」ボタンをクリック（pushした直後に表示される） または、「Pull requests」タブ → 「New pull request」をクリック
  3. ブランチの設定を確認する
    • base: main（マージ先）
    • compare: feature/divide（マージ元）
  4. タイトルと説明文を入力する
  5. 「Create pull request」をクリック

PRの説明文の書き方​

PRの説明文は「何を・なぜ・どうやって」変更したかを伝える重要な情報である。

以下のテンプレートを使うと、漏れなく情報を伝えられる。

## 何を変更したか
- Calculator クラスに割り算メソッド（divide）を追加した

## なぜ変更したか
- 四則演算の機能を完成させるため

## どうやって確認するか
- Calculator の divide メソッドを呼び出して、正しい結果が返ることを確認
- 0 で割った場合にエラーメッセージが表示されることを確認
ポイント

PRの説明文は、レビュアーが変更の意図を理解するための手がかりになる。 「何を変えたか」だけでなく、「なぜ変えたか」「どう確認するか」も書くことで、スムーズなレビューにつながる。

Step 3: コードレビューの進め方​

レビュアーの操作​

PRが作成されると、チームメンバー（レビュアー）がコードを確認する。

  1. PRの「Files changed」タブを開く
  2. 変更内容を確認する（追加行が緑、削除行が赤で表示される）
  3. 気になる行にカーソルを合わせ、+ ボタンをクリックしてコメントを書く
  4. コメントを書き終えたら「Start a review」をクリック
  5. すべての確認が終わったら「Review changes」をクリックし、以下のいずれかを選ぶ
選択肢意味使う場面
Approve承認問題なし。マージしてよい
Request Changes修正依頼問題あり。修正が必要
Commentコメントのみ承認でも却下でもない。質問や感想

レビューコメントの書き方​

良いコメントは、具体的で建設的なものである。

❌ 悪いコメント✅ 良いコメント
「これはダメ」「ゼロで割った場合の処理が必要です。if文でチェックしましょう」
「意味がわからない」「この変数名はもう少し具体的にできそうです。例えば result → quotient はいかがですか？」
（何もコメントなし）「このロジック、わかりやすくていいですね！」
重要

コードレビューは コードに対する指摘 であり、 人に対する批判 ではない。 「このコードは改善できる」と伝えるのであって、「あなたはダメだ」と言っているのではない。 良いところは積極的に褒めるコメントも書こう。

Step 4: 修正依頼への対応​

Request Changes を受けた場合​

レビュアーから修正依頼を受けた場合、以下の流れで対応する。

# 1. ローカルでfeatureブランチに切り替え
git switch feature/divide

# 2. 指摘された箇所を修正

# 3. 修正をコミット
git add Calculator.java
git commit -m "レビュー指摘を修正: ゼロ除算チェックを追加"

# 4. GitHubにpush（追加のコミットが自動的にPRに反映される）
git push

pushすると、PRに新しいコミットが自動的に追加される。 レビュアーは修正内容を確認し、問題なければApproveする。

Step 5: PRのマージとローカルの同期​

GitHub上でのマージ​

Approveされたら、「Merge pull request」ボタンをクリックしてマージする。

  1. 「Merge pull request」をクリック
  2. 「Confirm merge」をクリック
  3. 「Delete branch」をクリック（featureブランチはもう不要）

ローカルの同期​

GitHub上でマージが完了したら、ローカルのmainブランチを最新状態にする。

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

# 2. リモートの最新を取り込む
git pull

# 3. マージ済みのローカルブランチを削除
git branch -d feature/divide

PRマージ後の全体フロー​

ポイント

PRのマージ後は必ずローカルを同期すること。 git switch main → git pull → git branch -d ブランチ名 の3ステップを習慣にしよう。

Step 6: 実践課題​

課題1：PRの作成​

  1. feature/subtract ブランチを作成し、Calculator.java に引き算メソッドを追加してコミットせよ
  2. git push -u origin feature/subtract でGitHubにpushせよ
  3. GitHub上でPRを作成し、説明文を「何を・なぜ・どうやって」の形式で書け�

課題2：コードレビューの体験（ペアワーク）​

  1. ペアの相手が作成したPRの「Files changed」タブを確認せよ
  2. 少なくとも1つのコメントを書き、Approveまたは Request Changes を選べ
  3. 修正依頼を受けた場合は、修正してpushせよ

課題3：マージとローカル同期​

  1. ApproveされたPRをGitHub上でマージせよ
  2. ローカルで git switch main → git pull を実行し、変更が反映されていることを確認せよ
  3. git branch -d feature/subtract でブランチを削除せよ

まとめ​

この章では、 プルリクエストとコードレビュー について学んだ。

🎯 達成できたこと​

  • ✅ PRの意義（mainを守るレビュー体制）を説明できるようになった
  • ✅ GitHub上でPRを作成できるようになった
  • ✅ PRの説明文を「何を・なぜ・どうやって」の形式で書けるようになった
  • ✅ コードレビューでコメント・承認・修正依頼ができるようになった
  • ✅ PRマージ後にローカルを同期できるようになった

📚 学んだ内容​

  • PRはfeatureブランチの変更をmainに取り込む「依頼」である
  • PRを作成するにはfeatureブランチをGitHubにpushする必要がある
  • 説明文には「何を・なぜ・どうやって」を書く
  • レビューではApprove（承認）、Request Changes（修正依頼）、Comment（コメント）を選べる
  • PRマージ後は git switch main → git pull → git branch -d で同期する

🚀 次のステップ​

次の章では、 Issueとチーム開発実践 について学ぶ。 Issueで作業を管理し、PRと連携させることで、チーム開発の全体像を身につけよう。

💡 よくある質問​

Q1: PRを作成せずに直接mainにpushすることはできるか？​

A: 技術的にはできる。しかし、チーム開発では原則禁止である。GitHubの「Branch protection rules」を設定すれば、PRなしのmainへのpushを技術的にも防止できる。

Q2: PRのレビュアーは誰が設定するのか？​

A: PR作成時に「Reviewers」から指名できる。チームのルールによっては、特定の人が必ずレビューすることになっている場合もある。小規模チームでは、自分以外の全員がレビュアーになることが多い。

Q3: 1つのPRにどれくらいの変更を含めるべきか？​

A: 1つのPRは 1つの機能や修正に絞る のが原則である。変更が大きすぎるとレビューが困難になり、品質が下がる。目安として、変更ファイルが5-10個以内、レビューに30分以内で済む程度が理想的である。

Q4: PRでコンフリクトが表示された場合はどうすればよいか？​

A: ローカルでmainの最新を取り込み、コンフリクトを解決してからpushし直す。具体的には git switch feature/ブランチ名 → git merge main（ここでコンフリクト解決）→ git push の流れである。

Q5: Approve後にさらに変更を加えてもよいか？​

A: できるが、大きな変更を加えた場合は再度レビューを受けるべきである。Approve後の追加コミットでPRの意図が変わってしまうことを避けよう。

練習問題​

この章の内容を理解できたか確認しよう。

Pull Request（PR）の説明として最も適切なものを選べ。

正解

A. 変更をmainにマージする前にチームにレビューを依頼し、コードの品質を保つ仕組み

解説

Pull Request（PR） は、featureブランチの変更を main にマージする前に、チームメンバーにレビューを依頼する仕組みである。

PRの目的：

  • コードレビュー: バグや設計の問題を事前に発見する
  • 知識共有: チーム全員がコードの変更内容を把握できる
  • 品質保証: main ブランチに問題のあるコードが入るのを防ぐ

PRの流れ：

featureブランチ作成 → 開発・コミット → GitHubにpush
  → PR作成 → レビュー・修正 → approve → mainにマージ

PRとgit pullの違い：

  • git pull: ローカルでリモートの変更を取り込むコマンド
  • Pull Request（PR）: GitHubのコードレビュー機能（コマンドではなくWebUI操作）

名前は似ているが全く異なる概念である。

GitHubでPull Requestを作成する正しい手順を選べ。

正解

B. featureブランチをGitHubにpushし、GitHubのPull requestsタブから「New pull request」で作成する

解説

PRを作成する手順は以下の通りである。

ステップ1: featureブランチをGitHubにpush

git push origin feature/login

ステップ2: GitHubでPRを作成

  1. GitHubのリポジトリページを開く
  2. 「Pull requests」タブをクリック
  3. 「New pull request」ボタンをクリック
  4. base（マージ先）: main、compare（マージ元）: feature/login を選択
  5. タイトルと説明文を入力する
  6. 「Create pull request」をクリック

GitHubが表示するバナー： pushした直後にGitHubのリポジトリページを開くと、「Compare & pull request」という緑のバナーが表示されることが多い。これをクリックすると手順2〜6がショートカットできる。

レビュワーの指定： PRを作成する際に「Reviewers」でレビューしてほしい人を指定できる。

Pull Requestの説明文に含めるべき内容として最も適切なものを選べ。

正解

B. 変更の目的・変更内容の概要・テスト方法・関連するIssue番号を含める

解説

良いPR説明文には以下の情報を含めることが推奨される。

PR説明文のテンプレート：

## 変更の概要
ログイン機能を実装しました。

## 変更内容
- Login.java: ログインフォームのバリデーション追加
- UserService.java: 認証ロジックの実装

## テスト方法
1. アプリを起動する
2. /login にアクセスする
3. 正しいID/パスワードでログインできることを確認する

## 関連Issue
Closes #12

良いPR説明文のポイント：

  • レビュワーの時間を大切にする: 何をなぜ変更したかが一目でわかるように書く
  • テスト方法を明記する: レビュワーが動作確認できるよう手順を書く
  • 関連するIssueを紐づける: Closes #番号 でマージ時にIssueを自動クローズできる

PRの説明が充実しているほどレビューがスムーズになり、チーム全体の生産性が上がる。

GitHubのPull Requestでコードレビューを行う際の正しい説明を選べ。

正解

C. 変更点を確認し、問題があればコメントし、問題なければApproveしてマージを承認する

解説

コードレビューの一般的な流れは以下の通りである。

レビューの手順：

  1. PRの「Files changed」タブで変更内容を確認する
  2. 気になる行の左にある「+」アイコンでコメントを追加する
  3. 全体を確認したら「Review changes」ボタンをクリック
  4. Comment: 意見・提案のみ（マージを止めない）
  5. Approve: 承認（マージOK）
  6. Request changes: 修正を要求（承認なしにはマージできない設定も可能）

良いレビューコメントの書き方：

  • 「このコードは間違い」ではなく「〜のような問題が起きる可能性があります。〜に変更してはいかがでしょうか」
  • 指摘だけでなく、改善案も提示する
  • 良い点も積極的にコメントする（感謝・称賛）

コードレビューの目的：

  • バグの早期発見
  • コードの品質向上
  • チームへの知識共有

GitHubでPRがマージされた後、ローカルの main を最新状態に更新する手順の空欄を埋めよ。

$
$

解答例
git switch main git pull origin main
解説

GitHubでPRがマージされた後、ローカルの main ブランチを最新の状態に更新する手順は以下の通りである。

git switch main          # mainブランチに切り替える
git pull origin main     # リモートのmainを取り込む

なぜこの手順が必要か：

  • GitHubでPRをマージしても、ローカルの main は自動では更新されない
  • git pull を実行して初めてローカルにマージ内容が反映される

その後の後処理：

git branch -d feature/login   # マージ済みのfeatureブランチを削除

チーム開発での活用：

  • 自分のPRがマージされた後は必ず git switch main && git pull を実行する
  • 次のfeatureブランチは最新の main から作成する（git switch -c feature/次の機能）

ペアで以下の手順を実施し、PR作成からマージまでの操作を記述せよ。

  1. Aさんが feature/greet ブランチを作成し、Greeter.java を実装してコミットする
  2. Aさんが GitHubに push してPRを作成する（タイトル・説明文を書く）
  3. BさんがPRの「Files changed」でコードを確認し、コメントまたはApproveを行う
  4. AさんがPRをマージする
  5. Aさんがローカルの main を git pull で同期し、featureブランチを削除する

各手順で実行したコマンドとGitHub上での操作をまとめて記述せよ。

解答例
# Aさんの操作手順 # 1. featureブランチを作成して開発 git switch -c feature/greet # Greeter.java を作成・実装 git add Greeter.java git commit -m "Greeter.javaを追加" # 2. GitHubにpush git push origin feature/greet # 3. GitHubでPRを作成（WebUI） # base: main, compare: feature/greet # タイトル: "Greeter.javaを追加" # 説明文: 変更概要・テスト方法・関連Issue # Bさんの操作手順 # 4. PRをレビュー（WebUI） # Files changedで変更内容を確認 # コメントがあれば追加 # 問題なければApprove # Aさんの操作手順 # 5. PRをマージ（WebUI） # "Merge pull request" をクリック # 6. ローカルを同期 git switch main git pull origin main git branch -d feature/greet
解説

PRベースの開発フローは、現代のチーム開発の標準的な進め方である。

フロー全体のまとめ：

featureブランチ作成 → 開発・コミット → push → PR作成
  → レビュー → 修正 → Approve → マージ → ローカル同期

ペア演習のポイント：

  • AさんとBさんで役割を分担する（PRの作成者とレビュワー）
  • レビュワーは「Approve」だけでなく、コメントも追加してみる
  • 一度やったら役割を交代して両方の立場を体験する

このフローの利点：

  • main に直接コミットしないため、壊れたコードが混入しにくい
  • PRで変更の履歴と議論が残り、後から変更の意図を追える
  • コードレビューによって品質が向上し、メンバー同士で学び合える