この記事では、Pull Request（PR）とは何か、変更を話し合うためにどう役立つのかを説明し、IDEからPRを作成して確認する方法を紹介します。あわせて、よいコミットにするための3つのルールも見ていきます。これは大切な基礎です。Claude Codeはpull requestの準備やコメントを代わりに行えますが、それが何のためのものかを理解していてこそ、意識的に使いこなせます。
例と画面キャプチャはJetBrains IDEのものです。操作名や場所はお使いのバージョンによって異なる場合があります。練習には専用の学習用リポジトリを使ってください。実際のプロジェクトでは、ブランチ、コミット、変更の送信に関するプロジェクトのルールに従いましょう。
Pull Requestを使う理由
チームでは、変更を共通のブランチに取り込む前に話し合えると便利です。Pull requestを使うと、提案されたdiff、レビューコメント、チェック結果を一か所にまとめられます。マージの前に自分の変更を確認したい個人プロジェクトでも使われます。
PRを使うときは、まずマージの提案を作成します。GitHubではPull Requestと呼ばれ、ほかのプラットフォームではMerge Requestと呼ばれることもあります。具体的な進め方はチームが決めます。
Pull Requestは、"私のブランチの変更を取り込んで（pull）、メインブランチに追加（merge）してください"という正式な依頼です。ただの依頼ではなく、コードをmainに取り込む前に、話し合い、確認し、改善するための場所でもあります。
Claude Codeは、GitHub CLIなどを使ってPRのタイトルや説明、レビュー内容を準備できます。まず下書きを確認してください。PRの作成やコメントの送信はGitHubへの書き込み操作なので、あなたの指示があって初めて行います。
Pull Requestの標準的な流れ
新しい機能を追加するときの一般的な流れを、順を追って見ていきましょう。
ブランチを作る前に、作業元のブランチと、GitHub上の対象ブランチに対するコミット一覧を確認してください。関係のないローカルコミットが新しいPRに含まれてはいけません。"同期"のために機械的に送信するのではなく、作業に適した基点を選び、前の作業は別に保管しましょう。
手順1. 新しい作業用のブランチを作成します。ここで紹介するPRの流れでは、作業は専用のブランチから始めます。たとえば、コントリビューター向けのガイドファイルを追加するなら、feature/add-contribution-guideというブランチを作ります。
手順2. 変更を加え、ブランチをGitHubに送信します。新しいブランチにCONTRIBUTING.mdファイルを作成し（作成後にAddを押します）、ほかの開発者に向けたメッセージを書きます。その後、Commit and Pushを実行し、たとえばdocs: Add contribution guideのような分かりやすいメッセージを付けます。
ここが大事です。Pull Requestは、すでにリモートサーバー上にあるブランチをもとに作成します。そのため、PRを作る前に新しいブランチを必ずGitHubへpushしておく必要があります。
IDEからPull Requestを作成する
比較する2つのブランチを確認します。baseは変更を取り込む先のブランチ、compare/headは作業中のブランチです。PRを作成する前に、コミット一覧とdiffを確認してください。
ブランチがGitHubにあるので、Pull Requestを作成できます。
手順1. Pull Requestsタブを開きます。IDEの左側のサイドバーでPull Requestsタブを探します。開いたら+アイコン（またはCreate Pull Requestボタン）を押します。
手順2. PRの情報を入力します。IDEに使いやすい入力画面が表示されます。あとは内容をきちんと埋めるだけです。主な項目は次のとおりです。
- タイトル - IDEがブランチ名や最後のコミットメッセージを入力することがよくあります。変更の要点が伝わる、短く分かりやすいタイトルにしてください。
- 説明 - 何を変更したのか、なぜ変更したのかを、同僚に詳しく説明します。
- レビュアー（Reviewers） - 変更の確認を依頼する人です。承認が必須かどうかはリポジトリのルールで決まります。
- 担当者（Assignees） - 通常は作成者であり、レビュー後の修正を担当する自分を指定します。
Create Pull Requestを押す前に、base、head、diffをもう一度確認してください。まだレビューに出せる状態でなければ、利用できる場合はDraft PRを作成できます。通常のPRもDraft PRも、リポジトリへのアクセス権がある人には見えます。
コードレビュー - 確認と話し合い
PRを作成すると、最も重要な段階であるコードレビューが始まります。同僚はPRを開いて変更を確認し、コメントを残せます。
やり取りはすべてIDEのPull Requestsタブで確認できます。コードの行にコメントが付くと通知が届き、ブラウザーに切り替えずに返信できます。
修正を依頼されたらどうすればよいでしょうか。答えは簡単で、新しいPRを作る必要はありません。そのPRの元のブランチでコードを修正し、新しいコミットを作って送信します。GitHub上のPull Requestは自動的に更新され、既存の話し合いに新しいコミットが加わります。
Claude Codeはコードレビューにも参加できます。PRの変更を確認し、コメントを残すことができます。最初の確認役としては便利ですが、最終判断とコードへの責任はあなたとチームにあります。
作業の完了 - マージとブランチの削除
すべての指摘に対応し、チームが変更を承認したら（"approve"を受け取ったら）、Pull Requestをマージできます。通常はシニア開発者が行いますが、リポジトリで権限があれば自分で行うこともできます。
手順1. マージ。指摘事項、必須の承認、チェックのステータスを確認します。プロジェクトのルールと権限が許せば、利用可能な方法（merge、squash、rebase）を選び、確定してください。変更はPRの対象ブランチに入ります。この例ではmainです。
手順2. ブランチを削除。マージ後はfeatureブランチが不要になるため、リポジトリを散らかさないよう削除しておくとよいでしょう。GitHub側からDelete branchボタンで削除を提案してくれます。
マージ後はローカルでmainに切り替え、更新を取得して、PRの結果が反映されていることを確認します。必要な作業が残っていなければ、作業用のローカルブランチも削除できます。IDEから通常の方法で削除できない場合は、まず原因を確認してください。特にsquashやrebaseの後は注意が必要です。
よいコミットにする3つのルール
よいコミットは、メッセージだけでなく内容も適切です。変更履歴を分かりやすく役立つものにするため、次の3つのルールを意識しましょう。
ルール1 - 分かりやすいメッセージを書く
コミットメッセージは、チームや将来の自分に向けた伝言です。"fix"や"update"だけが並ぶ履歴では役に立ちません。よく使われる形式の1つにConventional Commitsがあります。次の構造を使います。
<タイプ>: <短い説明>
タイプには、変更の種類を表す短い単語を入れます。
feat- 新機能の追加;fix- 不具合の修正;docs- ドキュメントの変更;style- ロジックに影響しない書式の変更;refactor- 新機能の追加や不具合修正を伴わないコードの変更;test- テストの追加または修正;chore- 依存関係の更新やビルド設定など、定型的な作業。
例:
- よくない例:
fixed bug - よい例:
fix: Correct user login validation - よくない例:
readme - よい例:
docs: Update installation instructions
リポジトリで採用している形式に沿ってメッセージを書くよう、Claude Codeに依頼できます。チームで別の形式を選んでいるなら、Conventional Commitsを使う必要はありません。
ルール2 - 1つのコミットには1つの論理的な変更
不具合修正、新機能、既存コードのリファクタリングを1つのコミットに詰め込まないでください。そのようなコミットはレビューしにくく、問題を起こさずに取り消すのはほぼ不可能です。コミットごとに、具体的な作業を1つだけ扱いましょう。
- よくない例: "Update user page"という1つのコミットで、アバター欄を追加し、名前のバリデーションを直し、ボタンの色を変更する;
- よい例: 3つのコミットに分ける:
feat: Add avatar upload to user profilefix: Correct username validation logicfeat: Update button colors on user page
作業中に1つのファイルを大きく変更してしまった場合でも、IDEではファイル全体をコミットせずに済みます。Commit画面でファイルを展開し、該当する作業に関係する部分（chunks）だけにチェックを付けられます。
ルール3 - 変更結果を確認する
マージする前に、変更内容に合ったチェックを実行し、実際の結果を確認します。ドキュメントの修正と新しいロジックでは、必要なチェックが異なります。
リポジトリに自動チェックが設定されている場合、PRにそのステータスが表示されます。緑色のチェックマークは、実行された個別のチェックが成功したことを示すだけで、バグがない証明ではありません。何が実行され、何が未確認なのかを見ておきましょう。自動化の設定は別のテーマです。
Claude Codeと組み合わせるとどうなるか
PRはClaude Codeが特に役立つ場面です。注目したいのは次の点です。
- Claudeはあなたのブランチからpull requestを作成し、タイトルや説明も用意できます。GitHubでPRを作成する前に、文章を確認してください;
- PRの変更を確認し、最初のレビュー役としてコメントを残せます;
- プロジェクトのルールに沿ったコミットメッセージの作成を手伝います;
- 設定済みのチェック結果を読み取り、未確認の点を整理するのにも役立ちます。
PRはコードをmainに取り込む前に確認するためのものです。説明やレビューの一部をClaude Codeが作成した場合でも、最終承認とマージの責任は人にあります。Mergeを押す前に、何が取り込まれるのかを読んでください。
GO TO FULL VERSION