GitHubは、スタック型プルリクエスト（stacked pull requests）をパブリックプレビューに移行しました。これにより、開発者は大規模な変更を、個別にレビューおよびマージ可能な、依存関係のある一連のPRに分割できるようになります。

なぜこの機能が重要なのか

単一の巨大な（モノリシックな）PRは、レビューが1ヶ月にも及ぶほど膨れ上がることがよくあり、レビュアーは無関係なコードまで読み進めなければならない状況に追い込まれます。また、ベースブランチが更新されると、それらの巨大な変更はマージコンフリクトが発生しやすく、リリースの停滞を招く原因となります。スタック型PRは、1つの大きな差分を、前の差分に基づいた一連の小さく焦点を絞った差分に分割することで、これら両方の問題に対処します。

仕組み

最初にmainブランチに対して最初のPRを作成し、次にそのPRをベースとして次のPRを作成し、3つ目はその2つ目をベースにする、というように進めます。GitHubはこれらの関係性を自動的に追跡します。ベースとなるPRを修正（amend）すると、依存するPRは新しい状態を反映するように更新されます。レビュアーは、ワンクリックでスタック全体を承認することも、各レイヤーごとに承認することも可能です。

  • レビューの範囲が限定されるため、フィードバックが迅速になります。
  • 各PRが自身のレイヤーで導入されたコードのみに触れるため、コンフリクトが減少します。
  • UIにはスタックの階層が表示され、GitHub CLIを使えばワンライナーで一連のスタック型PRを作成できます。
gh pr create --title Feature A --base main
gh pr create --title Feature B --base feature-a
gh pr create --title Feature C --base feature-b

このコマンドラインの例では、前のPRに依存する3つのリンクされたPRを作成しています。同じワークフローはWebインターフェースからも利用可能で、他のPRを壊すことなく、スタック内のPRの順序を入れ替えたり削除したりできます。

メリットを受ける対象

大規模な機能開発チームやオープンソースのメンテナーは、レビュアーを無関係な変更の波にさらすことなく、段階的な作業をリリースできるようになります。また、各スタックレイヤーを独自のスケジュールでマージできるため、リリースマネージャーは何がリリース可能な状態にあるのかをより明確に把握できます。

注意点

この機能はまだプレビュー段階であるため、正式リリース前に変更される可能性があります。チームはブランチ作成に関する新しい習慣を取り入れる必要があり、一部がすでにマージされたスタックをリベースする際に、エッジケースに遭遇する可能性があります。ドキュメントはまだ整備中のため、早期導入者はUIの操作に慣れるまで追加の時間を要するかもしれません。

今後の注目点

GitHubは今後、codeownersや自動化ツールとのより緊密な連携を進める可能性が高く、コンフリクト削減に関するメトリクスが公開されるかもしれません。GA（一般公開）の時期に関するアップデートについては、プレビューの発表ページを継続的にチェックしてください。

まとめ: スタック型プルリクエストは、開発者が巨大な変更を制御するための実用的な手段を提供します。コンフリクトの多い単一のPRを、管理しやすくレビューしやすい一連の流れへと変えることができます。もし、あなたのワークフローが長いレビューやマージの悩みに直面しているなら、このプレビューを試してみる価値は十分にあります。