GitHub、stacked pull requestsを一般提供開始

GitHubは2026年10月6日、stacked pull requestsをすべてのgithub.comプランで一般提供した。スタックを使うと、開発者は1つの大きな変更を小さなプルリクエストの連なりに分割できる。各プルリクエストは1つずつレビューされ、その後まとめてマージされる。この機能は7月30日からパブリックプレビューとして提供されていた。GitHubによると、これを使うチームはすでにより多くのコードをマージしている。

スタック型プルリクエストとは

プルリクエスト（PR）は、あるブランチのコードを別のブランチにマージするよう求めるものだ。大きなPRはレビューに時間がかかる。レビュアーがすべてを一度に理解しなければならないからだ。

スタックは、その作業を層に分ける。各PRはその下のブランチをターゲットにするので、それぞれが自分の担当分の変更だけを示す。一番下のPRは、trunkとも呼ばれるメインブランチをターゲットにする。GitHubのchangelogによると、各層は個別のレビューとチェックを受けてから、まとめて取り込まれる。

マージは下から上へ進む。10月8日にセットアップガイドを公開したCCLeaksは、あるPRをマージすると、その下にある未マージのPRもすべて取り込まれると説明している。一番上のPRをマージすると、スタック全体がマージされる。ブランチのルールは引き続きすべての層に適用される。必須レビュー、ステータスチェック、コードオーナーも含まれる。

一般提供で変わったこと

10月6日のchangelogは、プレビュー以降の変更として次を挙げている。

変更	内容
承認がリベース後も残る	スタックをリベースしても、変更のないコードへの承認は保持される（古い承認を取り消す設定のリポジトリでも同様）
署名付きコミット	スタックのリベースで書き換えられたコミットは署名されたままで、元の作者も保持される
マージキュー	スタックは1つのグループとしてマージキューに入り、まとめて取り込まれる
マージコミット	マージコミット方式では、スタック内の各PRにそれぞれマージコミットが作られる
ベースブランチの削除	一番下のPRが閉じられる代わりに、スタックのターゲットが付け替えられる
バイパスによるマージ	リポジトリのルールをバイパスできるユーザーは、最も下にある未マージのPRをマージできる

GitHubによると、スタックの自動マージは「今後数週間で」順次提供される。PRのヘッダーにはスタックの詳細が表示されるようになり、タイムラインにはPRがスタックに加わった時と外れた時が記録される。Webhookでは、pull_requestイベントにstackedアクションが加わる。セルフホスト版のGitHub Enterprise Serverには、スタックが「今後のリリースで」提供される。

GitHubが示す数字

GitHubによると、スタックを使うリポジトリは、比較対象のリポジトリより9%多くのコードをマージした。マージまでの時間も5%改善したという。これらはGitHub自身の数字であり、changelogは比較グループをどう選んだかを説明していない。

初期ユーザーは満足しているようだ。changelogでは、Astralの創業者Charlie Marshの「GitHubのStacked PRsで一度マージしただけで、素晴らしいと結論づけた」という言葉が引用されている。7月のプレビュー記事では、VercelでNext.jsのリードを務めるTim Neutkensがこう述べた。「私たちはここ数か月、Next.jsでGitHubのstacked PRsを使ってきた」

スタックの始め方

スタックはgh stackで操作する。GitHubのコマンドラインツールであるGitHub CLIの拡張機能だ。CCLeaksは、要件としてGitHub CLI 2.90.0以降とGit 2.20以降を挙げている。GA版ではGitのworktreeにも対応した。worktreeを使うと、1つのリポジトリで複数のブランチを別々のフォルダーにチェックアウトしたままにできる。

CCLeaksのガイドによる基本的な流れは次のとおりだ。

1. gh extension install github/gh-stackで拡張機能をインストールする。
2. gh stack initでスタックを始め、各層ごとにgh stack add <branch>を実行する。
3. gh stack submitでPRを作成し、gh stack viewで連なりを確認する。
4. ベースブランチが進んだらgh stack rebaseを実行する。

7月のプレビュー記事によると、スタックはgithub.com上、GitHubモバイルアプリ、またはgh-stackスキルを使うGitHub Copilotのようなコーディングエージェントでも作成できる。Web画面では、Shift+JとShift+KでスタックのPR間を移動できる。

先に知っておくべき制限

この機能にははっきりした制約がある。CCLeaksは次の点を挙げている。

• 1つのリポジトリのみ。 すべてのブランチが同じリポジトリにある必要があり、フォークをまたぐスタックは使えない。
• 一直線のみ。 スタックは分岐できない。1つのPRが2つの子を持つことはできない。
• GitHub Desktopは非対応。 デスクトップアプリはスタックをサポートしていない。
• 古いマージ用エンドポイントは失敗する。 従来のPRマージAPIエンドポイントでは、スタックをマージできない。
• キューのグループが大きくなる。 スタックのマージキューのグループは、設定された最大サイズを最大50%超えることがある。1つのPRを外すと、その上のPRもすべて外れる。

開発者にとっての意味

大きな作業を手作業で依存関係のあるブランチに分けてきたチームは、組み込みのフローを使えるようになる。切り替える前に、いくつか確認しておきたい。

• 自動化を確認する。 古いAPIエンドポイントでマージするボットは、スタックでは失敗する。CCLeaksによると、スタックのデータはGitHub Actionsにgithub.event.pull_request.stackとして渡され、単独のPRではREST APIのstackフィールドはnullになる。マージボットを更新して、これを読み取るようにしたい。
• マージキューの上限を見直す。 CIの処理能力を守るためにキューでグループサイズを制限している場合、スタックによってグループがその上限を最大50%超えることがある。
• フォークからの貢献者は待つことになる。 フォークからの変更を受け付けるオープンソースプロジェクトは、まだそれらのPRをスタックにできない。
• Enterprise Serverのアップグレードは後で計画する。 セルフホストの顧客には日付が示されておらず、「今後のリリース」とあるだけだ。
• 1つの大きな変更で試す。 多くのファイルに触れるリファクタリングは、最初のテストにちょうどよい。3つか4つの層に分けて、レビューが早く戻ってくるか確かめたい。

9%という数字は、GitHubが自社製品について主張しているものだ。追跡する価値があるのは、導入前後の自分たちのレビュー時間である。