Git

プルリクエスト

中級

読み方：プルリクエスト｜英語：Pull Request

チームメンバーにコードレビューを依頼し、承認後にマージする仕組みだよ。Pull Request（PR）。

やさしい説明

プルリクエスト（PR）とは、チームメンバーにコードレビューを依頼し、承認後にマージする仕組みです。GitHub上で作成します。

「この変更をmainに入れていいですか？」とチームに確認を取るプロセスです。レビューでバグや改善点を指摘してもらえるので、コードの品質が上がります。

個人開発でも PR を作る習慣をつけると、変更の記録が残って便利です。

具体例・使い方

# 1. ブランチで作業してコミット
git checkout -b feature/header
git add .
git commit -m "ヘッダーコンポーネントを追加"

# 2. GitHubにプッシュ
git push -u origin feature/header

# 3. GitHubでPull Requestを作成
# 4. チームがレビュー → 承認 → マージ

PRの流れ（GitHub上での操作）

作業ブランチを作成し、変更をコミット・プッシュする
GitHubのリポジトリページに「Compare & pull request」ボタンが表示される → クリック
タイトルと説明（何を・なぜ変えたか）を書いてPRを作成する
チームメンバーが「Files changed」タブでコードを確認・コメントする
指摘事項があれば修正してコミット → 同じPRに追加される
レビュアーが「Approve（承認）」→「Merge pull request」でmainにマージされる

良いPR説明文の書き方

レビュアーが素早く内容を把握できるよう、以下を記載するのが一般的です。

変更内容 — 何を追加・修正・削除したか
変更理由 — なぜその変更が必要か
確認方法 — レビュアーがどのようにテストできるか
スクリーンショット — UI変更の場合は変更前後の画像

いつ使う？

チーム開発で変更をmainに入れるとき、コードレビューを受けたいとき、変更の意図を記録しておきたいときに使います。個人開発でも変更ログとして活用できます。

間違いやすいポイント

❌ PRが大きすぎてレビューが大変

1つのPRは「1つの機能」「1つの修正」に絞りましょう。100ファイル変更のPRはレビューに時間がかかり、バグも見落とされやすくなります。小さく分割することがチーム開発のコツです。

💡 draft PRを活用する

作業中の段階でもDraft（下書き）PRを作ると、進捗を共有したり早い段階でフィードバックをもらえます。レビュー準備ができたら「Ready for review」に変更します。

よくある疑問

Q: PRは1人開発でも使う？

A: 必須ではありませんが、変更の記録として使うと便利です。GitHub Pagesへのデプロイトリガーにもなります。

Q: PRの作り方は？

A: ブランチをpushした後、GitHubのリポジトリページで「Compare & pull request」ボタンをクリックします。

Q: レビューで指摘されたら？

A: 同じブランチで修正してpushすれば、PRに自動で反映されます。新しいPRを作り直す必要はありません。