Pull Request（PR）と review

01 / 10

main branch への直接 push を防ぐ

前の章では、main branch で作業して git push で remote に送信しました。1人だけの個人開発ならそれも可能です。

しかし複数人のチーム開発では、次のような深刻なトラブルが発生します。

バグを含む動かないコードが main に入り、チーム全員の開発が止まる
設計やセキュリティのまずいコードに誰も気づかないまま本番環境へデプロイされる
誰が・なぜその変更を入れたのか、経緯が分からなくなる

そのため、多くのチーム開発では「main branch への直接 push を禁止し、必ず review を経てから merge する」という運用ルールを徹底します。

02 / 10

Pull Request（PR）は Git の機能ではない

ここは非常に重要なポイントです。

Pull Request（PR）や Issue（課題管理）は、Git 本体の機能ではありません。git pull-request という Git コマンドは存在しません。

これらは GitHub や GitLab などの「Git repository をホスティングするサービス」が、Git の上に独自に追加したコラボレーション機能です（GitLab では「Merge Request（MR）」と呼びます）。

そのため、この教材でも PR や Issue の操作は端末コマンドではなく、remote repository（GitHub）画面のタブやボタンで操作します。

03 / 10

Issue — 要件・課題の管理

実際の開発現場では、いきなりコードを書き始めるのではなく、まず「不具合の報告」や「新機能の要望」を Issue として起票します。

Issue には一意の番号（#1, #2...）が採番され、担当者・議論の内容・進捗状況が記録されます。開発者はその Issue を解決するために branch を作成し、実装を開始します。

04 / 10

PR 開発の基本サイクル（6つのステップ）

チーム開発の流れは、常に次の6つのステップの繰り返しです。

1. 作業用 branch を作成してコードを変更し、commit する（git switch -c feature）
2. その branch をremote repository へ push する（git push origin feature）
3. GitHub 画面上でPull Request（PR）を作成する
4. 他の開発者がコード差分を確認し、review comment や承認（Approve） を行う
5. review 通過後、remote 上で main branch へ merge する（Merge pull request）
6. local repository で git switch main して git pull し、手元の main を最新化する

05 / 10

PR は「remote に push 済みの branch」に対して作成する

Pull Request を作成しようとしたときに branch が選択できない場合があります。これはlocal branch をまだ remote へ push していないことが原因です。

Pull Request は「remote repository 上にある指定の branch を、remote の main branch に merge してください」という依頼です。remote repository 上に存在しない branch は選択できません。

そのため、順番は必ず git push が先、Pull Request の作成が後になります。

06 / 10

review と指摘への対応（commit の追加 push）

Pull Request を作成すると、チームメンバーが変更差分を review できるようになります。

レビュアーから「この命名を修正してほしい」「テストを追加してほしい」といったreview comment がついた場合、PR を閉じたり作り直したりする必要はありません。

local で該当ファイルを修正し、通常通り commit して同じ branch 名へ git push するだけで、オープン中の Pull Request に変更が自動的に反映されます。

07 / 10

PR の merge（remote 上で merge commit が作られる）

review で承認を得たら、GitHub 上で「Merge pull request」ボタンを押して merge します。

このボタンを押すと、remote repository（GitHub のサーバー上）で git merge が実行されます。remote の main branch に、作業 branch を統合した merge commit が生成されます。

GitHub の UI ボタンは、remote 側で merge コマンドを実行するショートカットに過ぎません。

$ git log --oneline4c8e2a1 Merge pull request #1 from ramen9f2a1c4 ラーメンを追加

08 / 10

local の main は自動で更新されない

ここが初心者が最もつまずきやすい点です。

remote 上で Pull Request を merge しても、local repository の main branch は自動的には更新されません。

remote repository と local repository は物理的に独立した別々の repository です。remote で進んだ commit を local に取り込むには、必ず local 側で明示的なコマンド操作が必要です。

PR merge 後は必ず git switch main で main branch に切り替え、git pull を実行して local を最新状態に追いつかせましょう。

09 / 10

conflict 時の対応（手元で origin/main を merge して解消・再 push）

Pull Request のオープン中に、他のメンバーの PR が先に main に merge された場合、同じファイルの同一箇所が変更されているとconflict（競合）が発生し、merge ボタンが押せなくなります。

conflict の解消は、Pull Request を作成した開発者側の責務です。

1. git fetch で remote の最新の main（origin/main）を取得する
2. 自分の作業 branch 上で git merge origin/main を実行する
3. 発生した conflict を手動で解消し、commit する
4. git push で作業 branch へ再 push する

再 push が完了すると conflict が解消され、再び merge 可能な状態に戻ります。

10 / 10

実践の流れ

ここからは実際に Pull Request を用いたチーム開発の流れを体験しましょう。

画面下部の「remote repository（origin）」エリアに Pull Requests と Issues のタブがあります。これらの操作は端末コマンドではなく、画面上のタブやボタンをクリックして実行します。

Pull Request を作成するときは、merge 元の branch を選択し、変更内容のタイトルを入力して作成しましょう。