プル・リクエストとは

プル・リクエスト（PR）は、コードベースへの変更を提案する方法です。ソフトウェア開発者は、メインのコード・リポジトリー（リポジトリーとも呼ばれる）を別のブランチにフォークし、作業中にそのブランチにコードをコミットし、ブランチからメイン・コードに変更をプルまたはマージする前に、コード・レビューのために提案された変更にフラグを立てるためにプル・リクエストを作成します。

PRは、BitbucketやGitHubなどのGitリポジトリーで一般的なメカニズムです。GitLabでは、このプロセスに対してプル・リクエストではなく「マージ・リクエスト」という用語を適用しています。

開発者は、コマンドライン・インターフェース（CLI）またはWebインターフェースを使用してプル・リクエストを作成できます。新しいプル・リクエストは通常、バグの修正プログラム、依存関係の更新、新しい機能、またはリファクタリングされたコードのためにオープンされます。プル・リクエストは、コード・レビューを効率化し、コードベースを標準に保ち、ソフトウェア開発チームのメンバー間のコラボレーションを促進します。

PRを使用すると、開発者はソース・コードを作成し、ローカルでテストできます。コード変更はメイン・ブランチから分離されているため、開発者はコードベース全体を壊すことを心配する必要がありません。

プル・リクエスト手法には、主にオープンソース・プロジェクトに適用される3つの重要な役割が含まれますが、独自プロジェクトやクローズドソース・プロジェクトでも採用できます。

• 保守担当者：プロジェクト保守担当者は、プロジェクトを管理（多くの場合、所有者）し、PRを承認およびマージする、または拒否する権限を持っています。

• レビュアー：これらのチーム・メンバー（保守担当者自身でも、プロジェクトのエクスペリエンスが豊富な他の積極的なコントリビューターでもかまいません）は、コード品質に関する変更案をレビューし、必要に応じて改善を提案します。

• コントリビューター：これらの開発者は、変更を加え、プル・リクエストを開くといったタスクを担っています。

プル・リクエストの作成には、通常、次の7段階の手順が必要です。

1. 貢献者は、メイン・リポジトリーを分岐して新しいブランチを作成し（git checkout コマンドまたはWebインターフェースを使用）、このブランチをローカル・マシンに複製します。
   
   
2. コントリビューターは変更に取り組み、ローカルでブランチにコードをコミットします。
   
   
3. コントリビューターがコードを完了してテストしたら、まずメイン・リポジトリーから最新の更新を取得し、競合する変更を回避してから、コードをプッシュします。
   
   
4. コントリビューターは、提案された変更をメイン・ブランチに統合するために新しいプル・リクエストを開きます。
   
   
5. プル・リクエストが送信されると、レビュー担当者に通知が届きます。PRをチェックしてコントリビューターのブランチとメイン・ブランチの間の違い（差分とも呼ばれる）を比較し、コードをレビューし、最適化や改善が必要な領域についてコメントします。
   
   
6. コントリビューターは、レビュー担当者の提案と変更要求に基づいて追加のコミットメントを行います。
   
   
7. すべての変更が完了すると、レビュアーは保守担当者に通知し、保守担当者はPRを承認します。その後、プル・リクエストはメイン・リポジトリーにマージされます。

ソフトウェア開発チームは、ニーズに応じていくつかのPRワークフロー・オプションから選択できます。一般的なプル・リクエストのワークフローには、次のようなものがあります。

• フィーチャーブランチのワークフロー

• フォーキングのワークフロー

• git-flow

• スタックワークフロー

新機能のそれぞれには、その機能の目的を強調する説明的な名前が付いた独自の専用ブランチが付けられます。機能が完成すると、開発者は機能ブランチをメイン・ブランチにプッシュし、プル・リクエストを作成できます。

このワークフローでは、コントリビューターが個別に機能について作業するため、メイン・ブランチの安定性が維持されます。しかし、複数の機能ブランチの管理は困難になる可能性があります。

プル・リクエストの作成に関する前のセクションで概説した7ステップの手順は、フォーキングワークフローに対応しています。オープンソースのプロジェクトでは、継続的統合/継続的デリバリー（CI/CD）のプラクティスを補完するこのワークフローが採用されることが多いです。GitHubのフローは、フォークするワークフローと似たようなプロセスに従います。

ソフトウェアエンジニアのヴィンセント・ドリーセンは2010年にgit-flowを策定しました。通常、厳しいリリーススケジュールでソフトウェアを構築する場合や、さまざまなバージョンをサポートするソフトウェアを構築する場合に使用されます。

このワークフローは、以下の分岐で構成される分岐モデルに従っています。

• main 最新の安定版リリースを保持します

• develop 次のリリースに含まれる修正プログラム、機能、その他のコード変更の統合ブランチとして機能します

• feature 開発をソース・ブランチとターゲット・ブランチとして使用し、機能は準備できたら開発にマージされます

• release は、開発者からフォークされ、次のリリースのバージョン番号がタグ付けされ、出荷できるようになったときに、開発とメインの両方にマージされます。

• hotfix は、高優先度または重大度の高い本番環境の問題を修正するためにメインから直接フォークされ、修正が完了するとすぐに開発とメインの両方にマージされます。

開発者は、レビューが必要なhotfix、feature、およびreleaseブランチのプル・リクエストを作成します。

スタックワークフローは、大規模なタスクを、小さな段階的なコード変更のシーケンスに分解します。次のコード変更は前のコード変更に依存するため、プル・リクエストは相互に重ねて構築されます。

これらの機能の変更を伴う機能を考えてみましょう。データベースやデータ・モデル、API、フロントエンドです。従来の機能ブランチまたはフォーキングのワークフローでは、コントリビューターは、API更新を開始する前に、データベースまたはデータ・モデルの変更がレビューされ、承認され、メイン・ブランチにマージされるまでPRを待つ必要があります。スタックワークフローでは、この待ち時間がなくなり、コントリビューターはデータベースまたはデータ・モデルの変更から分岐してAPIの作業を開始し、それに対するPRを送信し、APIの変更からフロントエンドのタスクに取り組むことができます。

プル・リクエストには、次のようなメリットがあります。

• コラボレーションを促進

• コードの品質を向上

• 透明度を高める

• コーディング・スキルを強化する

プル・リクエストは協力関係を促進し、役割に関係なくチーム・メンバーが協力して作業することを奨励します。PRはフィードバックとその対処方法を促進し、議論を促し、改善のアイデアを生み出します。

PRはコード・レビュー・プロセスを開始し、バグ、コーディング・スタイルや標準からの逸脱、パフォーマンスの問題、セキュリティーの脆弱性を特定するのに役立ちます。この追加の監視により、コードの品質が維持され、さらには向上します。

プル・リクエストにより、チームはどのような変更が実装されたか、誰が行ったか、どこに適用されたか、およびその背後にある理由を確認できます。このような可視性により、コードベースとプロジェクト自体の状態をより詳細な洞察を得られるようになります。

レビュアーとコントリビューターの両方が互いに学び、その過程で新しい手法を見つけ、問題に対する斬新なアプローチを発見することができます。初心者や新しいチーム・メンバーは、以前のPRを研究してコードベースをより深く理解し、チームのコーディング基準とベスト・プラクティスを把握することもできます。

プル・リクエストの作成は簡単に思えますが、プロセスをさらにスムーズにするためのヒントとコツをいくつか紹介します。

• ドラフトを検討する

• 細部が重要

• 集中力を維持する

• 最新情報を入手

• テンプレートを取り入れましょう

ドラフト・プル・リクエストやマージ・リクエストは、開発者が進行中の作業を共有するための道として機能します。これにより、チーム・メンバーはコラボレーションをより早く開始し、より早くフィードバックを募集できるため、問題で行き詰まった人がチームメイトから潜在的な解決策をクラウドソーシングできます。

開発者は、新しいコミットについて、明確、簡潔、具体的なメッセージを提供する必要があります。明確さ、簡潔さ、具体性はPRタイトルや説明にも適用されるため、レビュアーがコード変更の背後にある意図をより簡単かつ迅速に把握できるようになります。

1つのPRに複数の問題をまとめると、レビューにかかる時間が長くなり、改訂の数も増加する可能性があります。各プル・リクエストは、バグ修正または機能に対して1つだけ対応する必要があります。集中的なプル・リクエストにより、より効率的なコード・レビューが可能になります。

コードをプッシュしてPRを開く前に、開発者はブランチが最新であることを確認する必要があります。最新の変更と新しいコミットを取得することで、プル・リクエストがマージされた後の競合を防ぎます。git pull コマンドを使用してターゲット・ブランチから変更を取得してマージするか、git rebase コマンドを使用してクリーンなGitコミット履歴を作成できます。

PR記述テンプレートは一貫性を確保し、コード・レビューを合理化するための重要なコンテキストを提供するのに役立ちます。チームは、バグ修正プログラム、機能、またはリファクタリングされたコードなど、さまざまなプル・リクエストタイプに対応するテンプレートを作成できます。

テンプレートは通常、マークダウン・マークアップ言語を使用して作成され、ルート・フォルダーまたはプロジェクト・リポジトリーのメイン・ブランチに配置されます。典型的なフィールドには、次のようなものがあります。

• 問題または機能の説明（参照用に、Jiraまたはその他の問題追跡ソフトウェアの対応するチケットへのリンク付き）

• コード変更の詳細な概要を説明するソリューション

• 単体テストや統合テストケースなどのテスト、テスト・カバレッジ、該当する場合はソリューションを手動で検証するステップ

• 構成変更

• 関連タスクのチェックリスト（コードのドキュメント化や、エラーや警告のないクリーンなコード・ビルドなど）

PRを自動化すると、プル・リクエストの作成からレビュー、マージまでのライフサイクルを短縮できます。PR自動化は、ボトルネックを緩和するためのシステムの層を含みます。

• スタックPR

• CI/CDパイプライン

• SDLC管理システム

• AI搭載のコーディング・アシスタント

ほとんどのGitリポジトリーはスタックワークフローをサポートするように設計されていませんが、一部のツールは、スタックされたプル・リクエストの同期やマージ競合の処理の複雑さを抽象化します。これらのツールには、CLIと、スタックされたPR用のMicrosoftのVS Codeの拡張機能およびそれらを管理するためのWebインターフェースを備えたGraphiteプラットフォームが含まれています。MetaのSaplingソース・コード管理システム。オープンソースのghstack CLIは、スタックされたdiffを個別のプル・リクエストとしてGitHubに送信します。

自動化されたDevOpsワークフローとして、CI/CDパイプラインはコードの品質を確保するのに役立ちます。GitHub ActionsやGitLabなどのプラットフォームやその他のCIツールは、単体テストや統合テストを実行し、PRのコード変更を表示およびテストするためのサンドボックスとして機能するプレビュー環境をデプロイできます。

CI/CDパイプラインはまた、安全なコーディング慣行を強化します。静的コード・アナライザーやその他の静的アプリケーション・セキュリティー・テスト（SAST）ツールは、ほとんどのCI/CD環境とシームレスに連携して、コードの脆弱性の可能性を正確に特定できます。DevOpsチームは、シークレットの検知のためのコミット前フックを実装できるため、開発者がコードをコミットしたりプル・リクエストを開始したりする前にシークレット・スキャンが必須のステップとなり、ハードコードされたシークレットを含む変更をブロックできます。

JiraやIBM Engineering Lifecycle Management（ELM）などのプラットフォームは、ソフトウェア開発ライフサイクル（SDLC）全体にわたるプル・リクエストの追跡と管理をサポートします。

ELMスイートの一部として、IBM Engineering Workflow Management（EWM）とIBM Engineering Integration Hubは、PRオートメーションを開発ワークフローに直接組み込んでいます。EWMはHubのコネクターを介してGitリポジトリーに接続し、作業項目からPRの作成をトリガーできます。要件または変更リクエストがEWMで承認されると、ルールによってリンクされたGitリポジトリーでプル・リクエストが自動的に開き、説明に事前入力できます。

ELMのAl駆動オートメーションは、PRが開かれると静的分析とテスト・スイートを実行し、成果を作業項目にポストして戻し、基準が満たされるまでマージをブロックすることもできます。一方、Hubはツール間でPRステータスを同期し、リポジトリーとEWMダッシュボードに反映してリアルタイムの可視性を実現します。

GitHub CopilotやIBM BobなどのAI搭載コーディング・アシスタントは、プル・リクエストのワークフローを強化できます。例えば、Bobは適切に形式化された意味のあるコミット・メッセージを生成できます。ブランチ名とコミット履歴を調べて、プロジェクトのスタイル規則に一致できるようにします。

Bobは開発者のIDEから直接プル・リクエストを作成することもできます。ブランチ名、コード変更、コミット履歴を分析して、目的と範囲を理解します。次に、変更を要約したPRタイトルと詳細な説明を生成し、自動的に検出してプル・リクエストの説明用のプロジェクトの既存のPRテンプレートを使用します。