Pull Requestとは：作成プロセスとコードレビュー

Pull Requestとは？

Pull Request (PR) は、分散バージョン管理システム内のあるブランチから別のブランチに変更を含めるための正式なリクエストです。PRはGitHub、GitLab、Bitbucketプラットフォームでの共同開発の中心的な要素であり、コードの議論、自動テスト、変更承認プロセスを組み合わせています。

“Pull Request” という名前は操作の本質を反映しています。開発者がリポジトリ所有者に変更を「プル」するようリクエストします。この用語は2008年にGitHubによって導入されました。それ以前は、パッチやmerge requests（GitLabの用語）の形で同様のメカニズムが存在していました。現在、PRはチームでのGit開発におけるデファクトスタンダードです。

GitHub Octoverse, 2025によると、89%のオープンソースプロジェクトが変更を行うためにPRの作成を必要としています。企業開発ではこの数字は95%に達します。PRは単なる技術ツールではなく、開発文化の一部となっています。PRを通じて知識の伝達、バグの発見、アーキテクチャ上の決定の調整が行われます。

Pull Requestの構成要素

典型的なPR は、タイトル、説明、変更されたファイルのリスト（diff）、レビュアーのコメント、CIチェックのステータスで構成されます。各PRは特定のソースブランチとターゲットブランチにリンクされており、マージ後に自動的に削除できます。

Pull Requestの作成方法

PRの作成 は、リモートリポジトリにフィーチャーブランチを公開することから始まります。プッシュ後、開発者はプラットフォームのインターフェースまたはCLI（gh、glab）を介してPRを開きます。GitHubを例にプロセスを見てみましょう。

ブランチのプッシュとPRの開始

最初のステップ は、フィーチャーブランチをリモートリポジトリにプッシュし、Webインターフェースまたはコマンドラインを介してPull Requestを作成することです。

# フィーチャーブランチを作成してプッシュする
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# GitHub CLIを介してPRを作成する
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

PRを作成すると、GitHub は自動的にCIパイプライン（GitHub Actions）を実行し、ターゲットブランチとの競合をチェックし、レビュアーを招待します。PR説明テンプレートは.github/PULL_REQUEST_TEMPLATE.mdを介して設定でき、すべてのPRに必要なセクション（目標、変更、テスト、関連タスク）を含めることができます。

説明とタグ付け

質の高いPR説明 には、タスクへのリンク（issue/ticket）、変更の簡単な説明、テスト手順、関連する変更のリストが含まれます。ラベル（bug、feature、refactoring）はPRを分類するのに役立ち、assigneesとreviewersはCODEOWNERSを介して自動的に割り当てられます。

# CODEOWNERSを介してレビュアーを割り当てる（リポジトリルートのファイル）
# .github/CODEOWNERSの例：
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# gh cliを介してレビュアーを割り当ててPRを作成する
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS は、変更されたファイルに基づいてレビュアーを自動的に割り当てるための標準的なGitHub/GitLabメカニズムです。たとえば、src/auth/ディレクトリ内の変更は、自動的にteam-authとsenior-devをレビュアーとして割り当てます。これによりプロセスが高速化され、適切な人がPRを確認できるようになります。

レビューに基づくPRの更新

レビュアーのコメントを受け取った後、開発者は同じフィーチャーブランチで修正を行い、新しいコミットをプッシュします。PRは自動的に更新されます。PRが既に開いている場合、公開されたフィーチャーブランチで履歴を書き換える（rebase）ことは重要ではありません。これにより、コメント内の特定のコミットへのリンクが壊れるからです。

# レビュアーのコメントに基づいて変更を加える
git checkout feature/biometric-auth
# コードを修正する
git commit -m "fix: handle biometric timeout per review"
git push

# PRは自動的に更新されます
# 承認後 — GitHubインターフェースを介してPRをマージする

コードレビュープロセス

コードレビュー はPull Requestの中心的な要素です。レビュアーは、正確性、コードスタイル、セキュリティ、アーキテクチャの一貫性について変更を確認します。質の高いレビューはバグを防ぐだけでなく、チーム内でコードベースに関する知識を広めます。

Googleの Engineering Practices（2025）は、以下のコードレビューの原則を推奨しています。レビュアーは変更のコンテキストを理解し、一般的な指摘ではなく具体的な推奨事項を提供し、技術的コメントとスタイル的コメントを分離する必要があります。レビュー時間はPR作成から24時間を超えてはいけません。

モバイル開発 の場合、コードレビューには特定のチェックが含まれます：targetSdkとの互換性、正しいlifecycle処理（Android）/ view lifecycle（iOS）、メモリリークの有無（LeakCanary、Instruments）、ダークテーマのサポート、ローカライゼーション。これらのチェックはリンターやDetekt/ktlintを通じて自動化できます。

コメントの種類

PRプラットフォーム は3種類のコメントをサポートしています：一般（PR全体に対するもの）、インライン（コードの特定の行に対するもの）、提案（置換コード付き）。提案によりワンクリックで変更を適用でき、プロセスを高速化し、反復回数を減らします。

すべてのコメントが 解決 され、CIチェックに合格した後、レビュアーは承認（Approved）を送信します。PRはマージできます。GitHubとGitLabはブランチ保護ルールをサポートしています：必要な承認数、必須CIチェック、PRなしでのmainへのプッシュ禁止。モバイルプロジェクトの場合、ブランチ保護にはビルド検証も含まれます：アプリケーションがビルドできない場合（gradle build failed / xcodebuild failed）、PRはマージできません。

PRでの競合解決

マージ競合 はPull Requestにおいて活発なチームワークでの一般的な状況です。プラットフォームはWebインターフェースを介した競合解決（単純な競合の場合）を提供するか、ローカルで解決することを推奨します。GitHub Actionsはフィーチャーブランチへのプッシュごとに自動的にマージ可能性をチェックし、マージが不可能な場合にPRを競合としてマークします。

Pull Requestのベストプラクティス

効果的なPull Requests はコードレビューを高速化し、バグの数を減らします。SmartBear（2025）の調査によると、200行までのコードのPRは1000行を超えるPRよりも2倍多くの有意義なコメントを受け取り、レビュー時間は3分の1に短縮されます。

• 小さなPR — 最適なサイズは100〜300行。大きなPRは論理的な部分に分割してください：各PRは1つのタスクを解決します。これによりレビューが簡素化され、競合の可能性が減少します
• 明確な説明 — Conventional Commitsに従ったタイトル（feat:、fix:、refactor:）、本文には「どのように」ではなく「何をなぜ」を含めます（コード自体が語ります）。テンプレート：目標 → 変更 → テスト → 関連issue
• 迅速なフィードバック — 24時間以内のレビュー。PRが1日以上待つと、チームはコンテキストを失い、マージ競合の数が増加します
• 自動化 — リンター、フォーマッター、テストはPR作成時に自動的に実行される必要があります。赤いCIチェックのあるPRのマージを許可しないでください
• Draft PR — 初期のアーキテクチャ議論に使用します。Draft PRはレビューを必要とせず、マージできませんが、初期段階で同僚にコードを見せることができます

追加のプラクティス：金曜日の夜にPRを作成しないでください（月曜日まで誰もレビューしません）、1〜2人にレビューを依頼してください（それ以上は品質を向上させずにプロセスを遅くします）、マージ前にsquash mergeを使用して履歴を圧縮してください。モバイルプロジェクトの場合、PRの説明にテストビルド（Firebase App Distribution / TestFlight）へのリンクを追加して、レビュアーが実行中のアプリケーションで変更を確認できるようにすることも推奨されます。

さまざまなプラットフォームでのPull Request

Pull Requestsを扱うための主要な プラットフォーム はGitHub、GitLab、Bitbucketです。共通の概念にもかかわらず、それぞれにチームのツールを選択する際に考慮すべき特徴があります。

GitHub は最大のコミュニティを持つ最も人気のあるプラットフォームで、CI/CD用のActionsと広範なアプリケーションエコシステム（GitHub Marketplace）を備えています。GitLab は統合されたCI/CDと完全なセルフホスト展開機能が特徴です。Bitbucket はJiraおよびAtlassianエコシステムと緊密に統合されており、企業環境で人気があります。

モバイル開発 の場合、プラットフォームの選択は多くの場合CI/CD機能によって決まります：GitHub ActionsはiOSビルド用のmacOSランナーをサポートし、GitLabにはiOS/Android用の組み込みランナーがあり、BitbucketはFirebase Test Labとよく統合されます。プラットフォームに関係なく、PRプロセスは同じです：ブランチ → レビュー → CI → マージ。