GitHub⁠Stacked PRsをプライベートプレビューで限定公開 —⁠—大規模プルリクエストを⁠レイヤーごとのプルリクエストのチェーンとして管理可能に

GitHubは2026年4月13日、プルリクエスト(PR)をデータモデル/API/UIといったレイヤーごとのプルリクエストのチェーンとして管理する「GitHub Stacked PRs」をプライベートプレビューで限定公開した。試すためには現在のところ、組織アカウントの入力を含むウェイトリストへの登録が必要となっている。

これまで、大規模な変更を含むプルリクエストはレビューが大変で、マージに時間がかかり、コンフリクトが発生しやすいのが一般的だった。

今回限定公開されたStacked PRsは、大規模な変更を伴うプルリクエストをレビューしやすくするように、論理的な単位ごとのレイヤーに小さく分割し、この分割したプルリクエストをチェーン(スタック)にして管理する機能となる。これにより、レビュアーは該当レイヤーのプルリクエストのコード差分のみを集中して確認できるようになる。

Stacked PRs自体は大規模プルリクエストの既存のコミットを、自動で別々のプルリクエストへ分割する機能ではない。これまで1つのブランチでまとめていた大きな変更を、作成者自身が複数レイヤーのブランチに分ける必要がある。

レイヤーの区切りはコミット単位ではなくブランチ単位で管理され、各レイヤーに対応するプルリクエストは1つ以上のコミットを含むかたちになる。そうしたレイヤーごとのブランチを用意したうえで、GitHub CLIの拡張機能やGitHubのUIを使ってプルリクエストをスタックとしてリンクすることになる。

たとえば、1つのブランチでまとめていた変更をfeat/auth-layer、feat/api-endpoints、feat/frontendといった複数レイヤーのブランチに分ける場合、ブランチの関係はmainからfeat/auth-layerを切り、その上にfeat/api-endpoints、さらにその上にfeat/frontendを積むことになる。

これに対応して、feat/auth-layerの変更はmain向け、feat/api-endpointsの変更はfeat/auth-layer向け、feat/frontendの変更はfeat/api-endpoints向けのプルリクエストになる。GitHub CLIでは後述のgh stack submitで各ブランチに対応するプルリクエストをまとめて作成でき、GitHubのUIでは最初のプルリクエストを通常通り作成したあと、後続のプルリクエストで「Start a pull request stack」「Add this pull request to an existing stack」を選択して順にスタックへ追加することになる。するとGitHubのプルリクエストの画面にはスタックマップが表示され、レイヤー間を移動できるようになる。

スタック内のプルリクエストは、スタック全体、またはその一部までをまとめてマージできる。処理はmainに最も近いプルリクエストから順に進み、今回の例でfeat/auth-layerのプルリクエストをマージすると、未マージのfeat/api-endpointsとfeat/frontendにはカスケーディングリベースが自動的に適用される。その後、未マージのうちmainに最も近いfeat/api-endpointsのプルリクエストは、main向けに更新される。

Stacked PRsをGitHub CLIで利用するための拡張機能はgh extension install github/gh-stackでインストールする。ワークフローとしては、gh stack initで新しいスタックを開始し、各レイヤーに対応するブランチを追加してリモートにプッシュし、最後にgh stack submitでGitHub上にスタックされたプルリクエストのチェーンを作成する。

# 新しいスタックを開始し、最初のブランチを作成する
# 既存のブランチ群をスタックに使う場合は --adopt を使う
gh stack init feat/auth-layer

# 最初のブランチで変更を行い、コミットする

# 上に新しいブランチを追加する
gh stack add feat/api-endpoints

# 追加したブランチで変更を行い、コミットする

# スタック内のブランチをまとめてプッシュする
gh stack push

# スタックの状態を表示する
gh stack view

# 各ブランチに対応するプルリクエストを作成し、GitHub上でスタックとしてリンクする
gh stack submit

また、リモートの最新状態を取り込みつつ、必要に応じてスタック全体を同期するgh stack sync、競合を解消しながらスタック全体をリベースするgh stack rebaseも用意されている。

制限事項として、スタック内の各ブランチ間には完全に線形な履歴が必要であり、フォークをまたいだスタックはサポートされない。また、チェーンの中間にあるプルリクエストをクローズすると、それより上のプルリクエストはマージできなくなる。なお現時点では、スタックの途中にブランチを挿入したり、順序を変更したりすることはできない。

GitHub CopilotなどのAIコーディングエージェント向けには、スタックの構成やgh stackに関するCLI操作を理解させるためのスキルも用意されており、npx skills add github/gh-stackで追加できる。これにより、対応したエージェントはスタックの作成や管理、スタック内の移動を行えるようになる。

おすすめ記事

記事・ニュース一覧