スキルアップカレッジ プルリクエストとコードレビュー——チーム開発のリズム
レッスン5：プルリクエストとコードレビュー——チーム開発のリズム
このレッスンで学ぶこと
- フォーク（fork）とクローン（clone）の違いを理解する
- プルリクエスト（PR）の作り方を整理する
- コードレビューの基本的な作法を持つ
- レビュー後のマージとブランチ削除の流れを理解する
- main ブランチ保護の発想を持つ
- 「Squash and merge」「Rebase and merge」など 3 つのマージ方法を把握する
前のレッスンでは、GitHub の使い方の基本（アカウント・リモート・push・pull・README・認証）を扱いました。今回のレッスンでは、GitHub での「チーム開発のリズム」の中核、プルリクエスト（Pull Request、以下 PR）とコードレビューを扱います。PR は GitHub が生み出した協業の発明と言ってよく、業界の開発スタイルを大きく変えました。
フォーク（fork）とクローン（clone）の違い
PR の前提となる「フォーク」と「クローン」を整理します。
フォーク（fork）
他人のリポジトリを、自分のアカウントの下にコピーする操作です。GitHub の Web 画面で「Fork」ボタンを押すと実行されます。
元のリポジトリ： github.com/original-owner/project
↓ Fork
自分のリポジトリ： github.com/your-username/project（コピー）フォーク後は、自分のリポジトリとして自由に編集できます。元の所有者から見ても、自分のフォークが独立したリポジトリです。
クローン（clone）
リモートリポジトリを、自分の PC（ローカル）に取り込む操作です。
git clone https://github.com/your-username/project.gitこれはレッスン 4 で扱ったとおり、ローカルでの編集と push のための準備です。
フォークとクローンの組み合わせ
OSS への貢献では、両方を組み合わせます。
- GitHub の Web 画面で元リポジトリを Fork（自分のアカウントの下にコピー）
- 自分のフォークを git clone でローカルに取り込む
- ローカルでブランチを切って編集
- 自分のフォークに push
- PR を出して元リポジトリにマージしてもらう
これが「OSS のコントリビュート（貢献）」の基本的な流れです。
自社内のチーム開発の場合
自社のリポジトリで複数人が開発する場合、Fork は使わず、
- 全員が同じリポジトリにアクセスできる（コラボレーターとして招待）
- 各人が同じリポジトリをクローン
- 各人がブランチを切って編集
- リポジトリに push
- PR を出してメンバーにレビューしてもらう
という流れになります。組織内では Fork を使わないのが一般的です。
💡 ポイント 「Fork は OSS のため」「組織内はコラボレーター招待」と覚えると、両者の使い分けが明確になります。
プルリクエスト（PR）とは何か
プルリクエスト（Pull Request、略して PR、GitLab では Merge Request）は、
「自分のブランチの変更を、別のブランチに取り込んでください」と依頼する仕組み
です。GitHub の発明により広まりました。PR には次の機能が組み込まれています。
- 変更内容（ブランチの差分）の可視化
- レビューのためのコメント機能
- ディスカッション（議論）の場
- マージ可否の判定（コンフリクトの有無、テスト結果）
- マージの実行ボタン
PR を介して変更が main ブランチに入る流れが、現代のチーム開発のリズムを作りました。
PR の作り方
ステップ 1：作業ブランチで commit
# main から作業ブランチを作る
git switch -c feature-add-contact
# 編集
echo "Contact page" > contact.md
# ステージング・commit
git add contact.md
git commit -m "Add contact page draft"ステップ 2：GitHub に push
git push -u origin feature-add-contactpush すると、GitHub の Web 画面に「Compare & pull request」というボタンが表示されます。
ステップ 3：PR を作成
「Compare & pull request」をクリックすると、PR 作成画面が開きます。
- タイトル：変更の要約（1 行）
- 本文：詳細な説明、変更の理由、テスト方法、スクリーンショットなど
- Reviewers：レビューを依頼する人を指定
- Assignees：作業を担当する人を指定
- Labels：分類用のラベル（bug、enhancement など）
- Projects：関連するプロジェクト（レッスン 6 で扱う）
- Milestone：マイルストーン（レッスン 6 で扱う）
「Create pull request」をクリックすると PR が作成されます。
PR の本文（説明）の書き方
良い PR の本文は、レビュー時間を大きく短縮します。
## 変更内容
- 連絡先ページの追加
- メールフォームの基本実装
## 変更理由
問い合わせ窓口がメールアドレスのリンクだけで、ユーザーから「フォームがほしい」と要望があったため。
## テスト方法
1. ローカルで `npm run dev` を実行
2. /contact ページにアクセス
3. フォームを送信してテストメールが届くことを確認
## スクリーンショット
（あれば添付）
## 関連 Issue
Closes #42「変更内容」「変更理由」「テスト方法」を明示するだけで、レビューする側がぐっと楽になります。
💡 ポイント 「Closes #42」のように Issue 番号を本文に書くと、PR がマージされたとき自動的に対応する Issue がクローズされます。便利な GitHub の機能です。
コードレビューの基本
PR が作られると、レビュアー（reviewers）がコードを確認します。これが「コードレビュー」です。
レビュアーが見るポイント
- 動くか（テストが通るか）
- 仕様を満たしているか
- 可読性は十分か
- 保守性は十分か
- セキュリティ上の問題はないか
- パフォーマンス上の問題はないか
- 命名・スタイルが揃っているか
すべてを 1 人で見るのは難しいので、組織やチームで「何を重点的に見るか」を揃えるのが普通です。
GitHub でのコードレビュー操作
PR の「Files changed」タブで、変更内容を行単位で見ながらコメントできます。
- 行をクリックすると「+」が出る → コメント開始
- 「Add single comment」または「Start a review」を選択
- 全体的なコメントは PR 本体に書く
- 「Approve」「Request changes」「Comment」のいずれかでレビュー結論を出す
レビュアーの心得
- 「人を批判する」のではなく「コードについて議論する」
- 「なぜそうしたか」を聞く
- 良い点も指摘する
- ブロッカー（必ず直してほしい）と提案（直してほしいが必須でない）を分ける
- 単なるスタイルの好みは控えめに
PR 著者の心得
- レビューに感謝する
- 反論があるなら丁寧に説明する
- 修正する場合は新しい commit を追加して push（PR が自動更新される）
- 「全部対応した」または「ここは対応しない（理由）」を明示する
⚠️ 注意 コードレビューはチームの心理的安全性に直結します。「指摘」が「攻撃」に感じられないよう、文面に気を配るのがレビュアーの責任です。
レビュー後のマージ
レビュアーが「Approve」を出すと、マージできる状態になります。
マージの 3 つの方法
GitHub の PR では、3 つのマージ方法が選べます。
1. Create a merge commit（マージコミットを作る）
ブランチの履歴をそのまま残し、マージコミットを追加する方法です。
main: ●─●─●─────●（マージコミット）
\ /
feature: ●─●- 履歴がそのまま見える
- ブランチの存在が明示的
- マージコミットで履歴がやや散る
2. Squash and merge（複数 commit を 1 つにまとめる）
ブランチの複数 commit を 1 つにまとめて main に追加する方法です。
main: ●─●─●─●（PR 全体の変更が 1 commit に）- main の履歴がきれい
- ブランチ内の細かい commit が消える
- 「PR 単位の commit」になる
3. Rebase and merge（rebase してマージ）
ブランチの commit を main の先端に積み直す方法です。
main: ●─●─●─●─●（feature の各 commit がそのまま main に並ぶ）- 履歴が一直線できれい
- ブランチの commit がそのまま残る
- 学習が要る（rebase は中級概念）
どれを選ぶか
組織のポリシーで決まることが多いです。
- 履歴を一直線にしたい → Squash または Rebase
- ブランチを明示的にしたい → Merge commit
- 細かい commit を残したい → Merge commit または Rebase
迷ったら「Squash and merge」が初心者には扱いやすいです。
マージ後のブランチ削除
PR がマージされたら、作業ブランチは役割を終えます。
- GitHub の PR 画面に「Delete branch」ボタンが表示される
- ローカルでも
git branch -d feature-add-contactで削除
ブランチを残しても害はありませんが、リポジトリが整理されません。定期的に削除する習慣を持ちましょう。
📝 補足 マージ済みのブランチを「あとから参照したい」場合、GitHub では削除後も PR 履歴から復元可能です（一定期間内）。気軽に削除して大丈夫です。
main ブランチの保護
main ブランチに「動かないコード」が直接入るのを防ぐため、GitHub には「ブランチ保護（branch protection）」機能があります。
ブランチ保護で設定できる項目
- main への直接 push を禁止（必ず PR 経由）
- PR には N 人以上の Approve が必要
- 自動テストの通過が必要
- マージ前に最新の main と同期している必要
- フォースプッシュの禁止
- 削除の禁止
設定方法
リポジトリの Settings → Branches → Add rule（または Add branch protection rule）から設定します。
業務での標準設定
業務リポジトリの最低限の保護として、
- main への直接 push を禁止
- PR には 1 人以上の Approve が必要
- 自動テストの通過が必要
を設定するのが現代の標準です。これにより、「テストを通っていないコード」が main に入る事故を防げます。
💡 ポイント ブランチ保護は、チーム開発の品質を支える基盤です。個人プロジェクトでも、複数の PC で作業する場合は設定しておくと、自分のミスを防げます。
講師の現場メモ：「PR レビューでチームが強くなった半年」
私（青木）が独立後、ある中堅製造業の社内開発チームを支援したときの話です。10 人のエンジニアが、main ブランチで直接 commit して push するスタイルで開発していました。当然のように、
- ある日突然、main が動かなくなる
- 誰がどの変更を入れたかわからない
- 同じファイルで衝突が頻発
- 新しいメンバーが「怖くて触れない」と漏らす
という状況でした。
私はリーダーに「PR を介したコードレビュー文化に移行しましょう」と提案しました。リーダーは「うちには時間がない」「レビュー文化なんてうちには根付かない」と最初は反対していました。
私は次のようなステップを提案しました。
- 1 か月目：main ブランチを保護、必ず PR 経由に
- 2 か月目：PR には 1 人の Approve を必須に
- 3 か月目：自動テスト（GitHub Actions）を導入、PR でテスト通過を必須に
- 4 か月目：「PR の本文は変更内容・理由・テスト方法を含める」テンプレ化
- 5 か月目：レビュー文化の振り返りミーティング
- 6 か月目：チームが自走するスタイルに
半年後、
- main が動かなくなる事故がゼロに
- 新メンバーが「PR を見れば、最近の変更がわかる」と言うように
- レビューでチームメンバーがお互いに学ぶ機会が増えた
- 同じファイルでの衝突は、コンフリクトとして PR の中で扱われ、main に直撃しなくなった
リーダーから「もっと早く始めればよかった」と笑いながら言われました。
そのときに痛感したのは、PR レビュー文化は「ツール導入」ではなく「チームの学習と心理的安全性の基盤」だ、ということです。コードを通じて議論する場が増えると、チームメンバーが互いに何を考えているかが見え、学習速度が上がります。
本コースで PR とコードレビューを丁寧に扱うのは、皆さんの組織にもこのリズムを持ち帰っていただきたいからです。
まとめ
このレッスンでは、以下のことを学びました。
- フォーク（Fork）：他人のリポジトリを自分のアカウントの下にコピー。OSS への貢献で使う
- クローン（Clone）：リモートをローカルに取り込む
- 組織内のチーム開発では Fork は使わず、コラボレーター招待が一般的
- PR は「自分のブランチの変更を別のブランチに取り込んでください」と依頼する仕組み
- PR の作り方：作業ブランチで commit → push → 「Compare & pull request」 → タイトル・本文・レビュアー・ラベルなどを設定
- 良い PR の本文：変更内容・変更理由・テスト方法・スクリーンショット・関連 Issue
- 「Closes #42」で Issue を自動クローズ
- コードレビューは「人を批判」ではなく「コードについて議論」。ブロッカーと提案を分ける
- マージの 3 方法：Create a merge commit、Squash and merge、Rebase and merge。組織のポリシーで決める
- マージ後はブランチを削除する習慣を持つ
- main ブランチ保護：直接 push 禁止、PR への Approve 必須、自動テスト必須、業務での標準
次のレッスンでは、Issue と GitHub Projects でタスクとコードを結ぶ進捗管理を扱います。
確認クイズ
このレッスンの理解度をチェックしましょう。