Pull Requestを体験する（Gitチーム開発）
Gitチーム開発シリーズ：なぜGitを使うのか｜WinFormsで2人開発を体験する｜コンフリクトを体験して解消する｜ブランチを体験する｜Pull Requestを体験する（今ここ）｜よくある失敗とFAQ｜4人チームでクイズアプリを作る｜[目次へ]
前回は、ブランチで検索機能を開発し、main に直接マージする流れを学びました。
実際の開発現場では、多くのチームが Pull Request（PR） を経由してマージします。今回は、PR を作成 → レビュー → マージする流れを体験しましょう。
この記事の目的
- Pull Request（PR）がなぜ使われるか理解する
- GitHub Desktop から PR を作成する
- Web の GitHub でレビュー・マージする流れを体験する
Pull Request（PR）とは
Pull Request は、「このブランチを main に取り込んでほしい」という依頼です。
直接マージ（前回）： ブランチ → GitHub Desktop で main にマージ
PR 経由（今回）： ブランチ → PR 作成 → レビュー → Web でマージPR を使うメリット
- レビュー：マージ前に、相手がコードを確認できる
- 履歴：何をなぜ変更したか、PR の説明として残る
- 安全性：確認してからマージするため、main を壊しにくい
前提条件
- ブランチを体験する の ①〜⑤ まで完了している
search_featureブランチに検索機能が完成し、動作確認済み- main にはまだマージしていない（⑥の直前の状態）
既に main にマージ済みの場合
03 を完了して main にマージ済みの場合は、新しいブランチ（例：add_feature）で「新規追加」などの発展機能を開発し、そのブランチで PR を体験できます。手順は同じです。
PR でマージする流れ
① Aさん：PR を作成する
やること
- GitHub Desktop で、現在のブランチが
search_featureであることを確認 - メニュー「Branch」→「Create Pull Request」をクリック
- ブラウザで GitHub の PR 作成画面が開く
- タイトル：例「検索機能を追加」
- 説明（任意）：例「名前の一部で検索できるようにしました」
- 「Create pull request」をクリック
※PR の作成・レビュー・マージは Web の GitHub で行います。GitHub Desktop は PR 作成の入口として使います。
② Bさん：PR をレビューする
やること
- GitHub のリポジトリページを開く
- 「Pull requests」タブをクリックする
- Aさんが作成した PR を開く
- 「Files changed」タブで、変更されたコードを確認する
- GitHub Desktopを開く
- 「Fetch origin」をクリックして、GitHub上の最新情報を取得する
- GitHub Desktopで、そのPRのブランチをチェックアウトする
- Visual Studioでプロジェクトを開く
- ビルドして、実際にアプリを起動する
- 変更した機能が正しく動くか確認する
- GitHubに戻り、「Files changed」タブを開く
- 「Submit review」をクリックして、レビュー画面を開く
- 「Approve」を選択し、コメント（任意）を書く
- レビュー画面内の「Submit review」をクリックして、レビューを送信する
レビューの種類
「Submit review」をクリックすると、レビューの種類を選択できます。
- Comment：コメントだけを送る（承認・修正依頼はしない）
- Approve：変更内容を承認する
- Request changes：問題点を指摘して修正を依頼する
今回の実習では、動作に問題がなければ Approve を選択します。
レビューのポイント
- 変数名・クラス名が分かりやすいか
- インデントが揃っているか
- if / for の書き方
- エラーなくビルドできるか
- フォームが正常に開くか
- ボタンを押したとき期待どおり動くか
- 入力値を変えても問題ないか
- 例外が発生しないか
※問題を見つけた場合は、修正箇所を直接書き換えるのではなく、「なぜ気になったのか」「どのように改善できそうか」をコメントで伝え、Aさんに修正してもらいます。
③ Aさん：PR をマージする
やること
- GitHub の PR ページを開く
- レビューが完了していることを確認
- 「Merge pull request」をクリック
- 「Confirm merge」をクリック
- （任意）「Delete branch」で
search_featureを削除してよい
④ 両者：ローカルを更新する
やること
- GitHub Desktop で 「Current Branch」 をクリック
- main を選択して切り替える
- Pull を実行
- main に検索機能が入っていることを確認
PR の流れのまとめ
| 手順 | 内容 |
|---|---|
| ① PR 作成 | ブランチの変更を「取り込んでほしい」と依頼する |
| ② レビュー | 相手がコードを確認し、承認する |
| ③ マージ | Web の GitHub で main に統合する |
| ④ Pull | ローカルの main を更新する |
直接マージと PR の違い
| 項目 | 直接マージ（03） | PR 経由（今回） |
|---|---|---|
| ツール | GitHub Desktop のみ | Desktop + Web の GitHub |
| レビュー | なし | マージ前に確認できる |
| 履歴 | マージの記録のみ | PR の説明・コメントが残る |
| 実務での使用 | 個人開発・小規模 | チーム開発で一般的 |
実務での PR の使い方
実際の開発では、次のような流れがよく使われます。
- ブランチで開発 → PR を作成 → レビュー → 承認 → マージ
- PR の説明欄に「何を変更したか」「なぜ変更したか」を書く
- レビューで指摘された点を修正し、再度 Push する
今回体験した「PR 作成 → レビュー → マージ」は、就職後の開発でも基本となるパターンです。
まとめ
- Pull Request：ブランチを main に取り込むための依頼。レビューを経てからマージする
- 流れ：PR 作成（Desktop）→ レビュー（Web）→ マージ（Web）→ Pull（Desktop）
- メリット：マージ前に確認でき、履歴が残り、main を壊しにくい
ブランチと PR を体験しておくと、チーム開発の実践力がさらに高まります。