この記事では、GitHub上での「プルリクエスト（PR）」の基本的な仕組みや使い方、PR作成からレビュー、マージまでの一連の流れを初心者向けに丁寧に解説します。この記事を読むことで、チーム開発で安全かつ効率的にコードをマージできるようになります。
プルリクエスト（PR）とは？
プルリクエスト（Pull Request）は、GitHubで行う変更提案の仕組みです。 自分の作業ブランチで行った変更を他のメンバーに見せて、レビュー・議論・承認を経て main ブランチなどにマージする流れをつくります。
なぜプルリクエストが必要なのか？
- チームで安全にコードを統合するため
- いきなり本番コードに反映せず、確認の機会を設けるため
- 誰が・なぜ・何を変えたかを明示できるため
なぜレビューが重要なのか？
- バグの早期発見や設計の見直しにつながる
- 複数人で品質を担保する意識がチーム全体に浸透する
- 書いた人とは異なる視点でコードをチェックできる
💡 「コードの変更内容」と「その背景・意図」まで共有できるのがPRの特徴です。
プルリクエストの基本構造
プルリクエスト（PR）は、GitHubでのコードレビューやマージの起点となる重要な仕組みです。PRには、どのブランチに何を反映させたいのか、どのような変更なのか、誰にレビューしてほしいのかといった情報が含まれており、チームでの協調開発を円滑に進めるために欠かせません。
PRの作成画面は下記のようになっています。いろいろ設定できますが、最初は「baseブランチ」「compareブランチ」「レビュアーのアサイン設定」「タイトル・本文」まで覚えておけば問題ありません。
PRは、以下のような構成で成り立っています：
- baseブランチ：変更を取り込みたい先（例：
main）。通常は本番用（main）や開発用（develop）になることが多いです。 - compareブランチ：変更を提案する側のブランチ（例：
feature/login）。自分が作業していたブランチを指定します。 - タイトル・本文：このPRで何を変更したのか、なぜその変更が必要なのかを記載します。読み手が理解しやすいよう簡潔にまとめましょう。
- レビュアーのアサイン設定：誰にレビューしてほしいかを指定します。レビュー対象者に通知され、確認・コメント・承認が行われます。
💡プルリクエストは「変更を提案する＋説明する＋レビューを依頼する」という複合的な役割を持っています。
プルリクエストの作成手順
実際に適当なリポジトリをcloneしてきて、修正してからPRを上げてみましょう。今回は筆者が管理している個人のGitHubでPRをあげてみます。
手順1. リモートリポジトリをcloneして作業ブランチを切る
https://github.com/tamotech1028/factory-method
このリポジトリを下記のコマンドでcloneする
git clone https://github.com/tamotech1028/factory-method.git
次に、現在の作業ブランチがmainであることを確認した後に、下記コマンドで機能追加用ブランチにcheckoutoする
git checkout -b feature/tamotech
手順2. コードを変更して git add → git commit → git push
適当にコードを変更します。このブランチはjavaで書かれているので、適当な機能を追加してみます。何度かcommitを行ってgit pushでリモートリポジトリにアップロードしました。
おそらくgit pushだけを行うとpushに失敗したエラーメッセージが出るかもしてません。下記のエラーは、ローカルブランチをGitHubに初めてpushしようとしたときに表示されるエラーです。
factory-method % git push
fatal: The current branch feature/tamotech has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin feature/tamotech
To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.これは現在のブランチ（feature/tamotech）が、リモートリポジトリ上のどのブランチと対応（追跡）しているかが「設定されていない」ため、Gitはどこにpushすべきか分かりません。エラー分の中に対処方法もあるためその通りに実行してみましょう。必ずうまく行くはずです。
% git push --set-upstream origin feature/tamotech
Enumerating objects: 20, done.
Counting objects: 100% (20/20), done.
Delta compression using up to 8 threads
Compressing objects: 100% (15/15), done.
Writing objects: 100% (15/15), 1.91 KiB | 1.91 MiB/s, done.
Total 15 (delta 8), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (8/8), completed with 3 local objects.
remote:
remote: Create a pull request for 'feature/tamotech' on GitHub by visiting:
remote: https://github.com/tamotech1028/factory-method/pull/new/feature/tamotech
remote:
To github.com:tamotech1028/factory-method.git
* [new branch] feature/tamotech -> feature/tamotech
branch 'feature/tamotech' set up to track 'origin/feature/tamotech'.リモートリポジトリにfeature/tamotechブランチを新しく作って、そこにpushした内容が書かれています。これでGitHub上にpushすることができました。
手順3. GitHub 上で「Compare & pull request」ボタンをクリック
GitHubにpushしたらGitHubの該当のリポジトリを確認してみましょう。すると、直近でpushされたブランチの情報が黄色の枠でハイライトされているはずです。
ここにハイライトされるのは、直近のpushに対してのみです。しばらく時間が経つとここには表示されなくなるため「Pull requests」タブからPRを作りましょう。
手順3. PRのタイトル・説明を記入し、レビュアーを設定して作成
プルリクエストの基本構造で添付した画面でタイトルや本文、レビュアーを設定しましょう。本文はMarkdown形式で書かれています。GitHubでは、README.mdやプルリクエストの説明欄など、多くの場所でMarkdownが使えます。
PRの本文で記入すべきこと
PRを出す際には、以下の内容を明確に書くことでレビューがスムーズになります：
- 変更の概要：何をどのように変えたかを簡潔に説明（例：「ログイン画面のバリデーション処理を追加」）
- 背景・目的：なぜこの変更が必要だったか（例：「不正な入力を防止するため」）
- 関連Issueやチケット：該当する課題番号など（例：
Closes #42） - 動作確認内容：手元で試した内容やスクリーンショット
- レビューしてほしいポイント：迷っている箇所や重点的に見てほしい部分
これらはあくまで一例です。チーム状況や開発状況に応じて、適宜レビューに必要な情報を記載しましょう。誰が読んでもわかるような文章にするのが「良いPR」です。
レビューとコメントの流れ
プルリクエストを出すと、指定されたレビュアーがコードを確認し、コメントや修正提案を行います。これは単なるコードチェックではなく、チームでの対話・品質保証・知識共有の場として非常に重要です。
レビューの基本的な流れ：
- レビュアーがPRにアクセスし、変更点を確認
- GitHub上では差分（diff）表示を通じて、何がどのように変更されたかを視覚的に確認できます。
- コメントを追加
- 気になる箇所や改善点があれば、該当行にコメントを残します。
- 質問や提案、バグの指摘、読みやすさに関する意見なども含まれます。
- 修正と再push
- コメントを受けて、作成者はローカルで修正し、再度コミット＆pushします。
- 変更は同じPRに自動的に反映されます。
- 最終レビューと承認（Approve）
- すべての修正が完了し、問題がなければレビュアーがApproveを出します。
- マージ可能状態に
- 承認されたPRは、マージボタンが有効になり、レビュー完了として処理できます。
💡レビューは「ダメ出し」ではなく「協力と対話」。改善点を共有し、良いコードを一緒に育てる姿勢が大切です。改善点だけではなく、修正の良かった点等もコメントすることでモチベーションの向上にもつながります。
💡 PRの過程は記録として残るため、後から見返して知見を得たり、経緯を確認するのにも役立ちます。
💡 コミット単位で細かく変更理由を記録しておくと、PRでのレビューがスムーズになります
マージの方法と種類
マージの方法と種類PRが承認されたら、変更を main ブランチなどに取り込む「マージ」を行います。GitHubでは次の3種類のマージ方法が選べます。それぞれの特徴や使いどころを理解して、プロジェクトに合ったものを選びましょう。
▶︎ Merge Commit（マージコミット）
- そのままマージし、マージ専用のコミットが追加される
- ブランチの履歴が明確に残る
- 複数人の開発や履歴の追跡を重視するチームに最適
▶︎ Squash Merge（スカッシュマージ）
- 複数のコミットを1つにまとめてマージ
mainの履歴をすっきりさせたいときに便利- 細かいコミットが多いときや、履歴を整理したいプロジェクト向け
▶︎ Rebase Merge（リベースマージ）
- 変更を
mainに直列で追加するように並べ替えてマージ - 履歴がきれいになるが、競合が起きやすく上級者向き
- 履歴重視だがマージコミットを避けたい場合に使用
💡 どの方法を使うかは、チームで方針を統一しておくと混乱を防げます。
まとめ
プルリクエストは、GitHub上で安全かつ透明性のあるチーム開発を支える仕組みです。 「書いたらすぐマージ」ではなく、「共有 → レビュー → マージ」という流れが、品質とチーム力を高める大きなポイントになります。
また実務ではチームでのルール作りが非常に大切になります。ブランチの構成や命名ルール、レビューフロー、PRテンプレート、コミットの大小等、非常に重要です。次回の記事では、チーム運用でのルール作りについて詳しく解説します。
