プルリクエストとは何か
チーム開発で使われるプルリクエストの仕組みを理解しよう
ローカルマージの振り返り
前の章では、ブランチを作って作業し、git merge で main に直接マージする流れを学びました。
ブランチを作る→作業・コミット→main に切り替え→git merge（直接マージ）
この方法は手軽ですが、チーム開発では マージする前に他の人に確認してもらいたい 場面がほとんどです。
そこで登場するのが プルリクエスト です。
プルリクエストとは
プルリクエスト（Pull Request、略して PR） は、GitHub 上で「この変更を取り込んでください」と依頼する仕組みです。
で直接 git merge する代わりに、GitHub 上でチームメンバーに レビュー（確認） してもらってからマージします。
| ローカルマージ | プルリクエスト | |
|---|---|---|
| マージする場所 | 自分のPC | GitHub 上 |
| 他の人の確認 | なし | レビューしてからマージ |
| 変更内容の共有 | 自分しか分からない | GitHub で誰でも見られる |
チーム開発では、メインブランチへの直接マージは明確に禁止されていることが多いです。
なぜプルリクエストを使うのか
- コードレビュー: 他の人に変更内容を確認してもらえる
- 議論: コードについてコメントで議論できる
- 品質の維持: 問題のあるコードが main に入るのを防げる
- 記録: 何のために、どんな変更をしたかの記録が残る
プルリクエストの流れ
ブランチを作る→変更してコミット→GitHub に push→PR を作成→レビュー→マージ
- ブランチを作る: main から新しいブランチを作成
- 変更してコミット: ブランチ上でコードを変更し、コミット
- GitHub に push: の変更を GitHub に送る
- PR を作成: GitHub 上でプルリクエストを作る
- レビュー: チームメンバーが変更内容を確認
- マージ: 問題なければ main にマージ
セクションまとめ
- ✓プルリクエストは「変更を取り込んでください」と依頼する仕組み
- ✓コードレビューで品質を維持できる
- ✓ブランチ作成 → 変更 → push → PR作成 → レビュー → マージ の流れ