Pull Requestを体験する（Gitチーム開発）
Gitチーム開発シリーズ：なぜGitを使うのか｜WinFormsで2人開発を体験する｜コンフリクトを体験して解消する｜ブランチを体験する｜Pull Requestを体験する（今ここ）｜[目次へ]
前回は、ブランチで検索機能を開発し、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」タブで、変更されたコードを確認
- 確認したら「Review changes」→「Approve」を選択し、コメント（任意）を書いて「Submit review」をクリック
レビューのポイント（講師ガイドのペア内コードレビューと同様）
- 変数名・クラス名が分かりやすいか
- インデントが揃っているか
- if / for の書き方
※ヒントだけ伝え、答えは直接言わない、という姿勢が実務に近いです。
③ 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 を体験しておくと、チーム開発の実践力がさらに高まります。
訪問数 3 回, 今日の訪問数 3回