プルリクエスト

プルリクエストは、GitHubによって普及したメカニズムであり、特にオープンソースプロジェクトにおいて、作業の統合を容易にするために使用されます。貢献者は、中央リポジトリのフォーク（クローン）で自分の貢献作業を行います。貢献が完了したら、プルリクエストを作成して、中央リポジトリの所有者に、自分の作業がメインラインにマージできる準備ができたことを通知します。ツールは、リクエストを受け入れる前に、貢献物のコードレビューをサポートし、促進します。プルリクエストはソフトウェア開発で広く使用されるようになりましたが、継続的インテグレーションを妨げる統合摩擦の増加を懸念する声もあります。

プルリクエストは、特に分散型ソースコード管理システム（Gitなど）を使用する多くのオープンソースプロジェクトで存在していた開発ワークフローのための、便利なツールを提供します。このワークフローは、貢献者が新しい論理ブランチを作成することから始まります。これは、中央リポジトリで新しいブランチを開始するか、個人リポジトリにクローンを作成するか、またはその両方によって行われます。その後、貢献者はそのブランチで作業を行い、通常はフィーチャブランチのスタイルで、メインラインからの更新を自分のブランチに取り込みます。作業が完了したら、中央リポジトリの管理者と連絡を取り、作業が完了したことを、コミットへの参照と共に伝えます。この参照は、統合する必要があるブランチのURL、またはメール内のパッチのセットである可能性があります。

管理者はメッセージを受け取ると、コミットを調べて、メインラインに入れる準備ができているかどうかを判断します。準備ができていない場合は、貢献者に変更を提案し、貢献者は提出内容を調整する機会を得ます。すべてが問題なければ、管理者は通常のマージ/リベース、または最終メールからのパッチの適用によってマージできます。

GitHubのプルリクエストメカニズムにより、このフローがはるかに容易になります。フォークメカニズムを通じてクローンを追跡し、プルリクエストを議論するためのメッセージスレッドを自動的に作成し、レビューワークフローのさまざまなステップを処理するための動作を備えています。これらの利便性は、GitHubが成功した大きな要因であり、「プルリクエスト」が開発者のレキシコンの重要な部分になった理由です。

これがプルリクエストの仕組みですが、使用するべきかどうか、そしてどのように使用するべきかについてはどうでしょうか？その質問に答えるために、メカニズムから一歩下がって、ソースコード管理ワークフローにおけるその動作について考えてみたいと思います。そのために、ソースコードブランチ管理のパターンをいくつか書き留めました。（特にベースとインテグレーションのパターン）を理解することで、プルリクエストの役割が明確になります。

これらのパターンに関して、プルリクエストはフィーチャブランチと統合前レビューの組み合わせを実装するように設計されたメカニズムです。したがって、プルリクエストの有用性を評価するには、まずこれらのパターンが私たちの状況にどの程度適用できるかを検討する必要があります。ほとんどのパターンと同様に、それらは場合によっては価値があり、場合によっては非常に面倒です。私たちは、具体的な状況に基づいてそれらを検討する必要があります。フィーチャブランチは、論理的な貢献をまとめて、単一単位として評価、承認、または延期できるようにする良い方法です。これは、貢献者がメインラインに直接コミットすることを許可されていない場合に非常に理にかなっています。しかし、フィーチャブランチには、統合の頻度が通常制限され、複雑なマージにつながり、リファクタリングを妨げるというコストがかかります。統合前レビューは、統合摩擦の著しい増加を犠牲にして、コードレビューを行う明確な場所を提供します。[1]

これは状況の非常に簡略な概要ですが（フィーチャブランチの記事でこれについてさらに説明するには、はるかに多くの言葉が必要です）、これらのパターン、そしてプルリクエストの価値は、主にチームの社会構造に依存するという事実に行き着きます。プルリクエストでうまく機能するチームもあれば、プルリクエストによって効率性が大幅に低下するチームもあります。プルリクエストは非常に人気があるため、多くのチームが、プルリクエストなしの方がうまくいく場合でも、デフォルトでそれらを使用しているのではないかと思います。

プルリクエストはフィーチャブランチ向けに構築されていますが、チームは継続的インテグレーション環境内でそれらを使用できます。これを行うには、プルリクエストを十分に小さくし、チームを十分に反応させる必要があります。これにより、全員が少なくとも毎日メインライン統合を行うというCIの経験則に従うことができます。（そして、メインライン統合は、現在のメインラインをフィーチャブランチにマージするだけではないことを思い出させておきましょう）。ship/show/ask分類を使用すると、プルリクエストをよりCIに適したワークフローに統合する効果的な方法になります。

プルリクエストの広範な使用は、プルリクエストが統合前レビューのための明確なポイントと、それを促進するツールを提供するため、コードレビューのより広範な使用を促進しました。コードレビューは良いことですが、プルリクエストだけがそれを使用できるメカニズムではないことを覚えておく必要があります。多くのチームは、ペアプログラミングによって提供される継続的なレビューに大きな価値を見出しています。統合頻度を減らすために、統合後のコードレビューをいくつかの方法で実行できます。正式なプロセスは各コミットのレビューを記録するか、テクニカルリードが数日ごとにリスクの高いコミットを調べることができます。おそらく最も強力なコードレビューの形式は、頻繁に見過ごされているものです。コードベースを、繰り返し反復によって着実に改良できる流動的なシステムとみなすチームは、開発者が既存のコードを見るたびにリファインメントコードレビューを実行します。プルリクエストがないとコードレビューができないと言う人がよくいますが、それは間違いです。統合前コードレビューはコードレビューを行う方法の1つにすぎず、多くのチームにとって最良の選択肢ではありません。