プルリクエスト(Pull Request、略してPR)は、Git のブランチで行った変更を、別のブランチ(多くは main)へ取り込んで(マージして)もらうよう提案する仕組みです。GitHub や GitLab(GitLabではマージリクエストと呼ぶ)などのホスティングサービスが提供する機能で、変更をいきなり本流へ入れず、レビューと議論を挟んでから統合するための入口になります。
まず押さえたいポイント
- 変更を提案する単位であり、差分・コミット履歴・レビューコメントがまとまって表示される。
- レビュアーが内容を確認し、承認されればマージされる。CIによる自動テストと組み合わせることが多い。
- Git 標準のコマンドではなく、GitHub / GitLab などの機能である点は fork と同じ。
どんな場面で使うか
- チーム開発で、main へ直接コミットせずレビューを通してから統合したいとき
- OSSへの貢献で、fork した自分のコピーから本家へ変更を提案するとき
- 変更の意図を説明し、議論の記録を残したいとき
よくある誤解や注意点
「プルリクエスト」という名前から「pull(取ってくる)操作」と誤解されがちですが、実際は「自分の変更をあなたのブランチへ pull(取り込んで)ください」とお願いする提案です。作業前にブランチを分け、1つのPRは1つのテーマに絞るのが基本で、巨大なPRはレビューが難しくなります。マージ方法(マージコミット / スカッシュ / リベース)はチームの方針に合わせます。
もう一つ、初心者がつまずきやすいのがPRの向き(送り先)です。PRは「どのブランチを、どのブランチへ取り込むか」を指定します。同じリポジトリ内なら「作業ブランチ → main」、fork を使う場合は「自分のforkのブランチ → 本家(upstream)のmain」となり、送り先を間違えると意図しない相手にレビュー依頼が飛びます。また、PRを出した後もブランチに追加でコミットして push すれば、その変更は同じPRに自動で反映されます。レビュー指摘への修正は新しいPRを作り直すのではなく、同じブランチへ積むのが基本です。GitLab では同じ仕組みをマージリクエスト(MR)と呼びますが、役割は同じです。fork を使ったOSS貢献の流れは Gitのforkとcloneの違い で具体的に整理しています。