GitHubの「Stacked pull requests」が一般提供に。仕組みとgh stackの始め方

2026年10月6日、GitHubの「Stacked pull requests」(スタックされたプルリクエスト)が一般提供(GA)になりました。大きな変更を、小さなプルリクエストの積み重ねに分けてレビュー・マージできる機能です。

この記事では、GitHubのChangelogと公式ドキュメントをもとに、スタックの仕組み、GAで入った変更点、gh stack 拡張での始め方、導入前に確認しておきたい点を整理します。

この記事が関係する人・関係しない人

関係する人

• github.comで、大きな変更を依存順の小さなPRに分けてレビュー・マージしたい人やチーム

• PRのベースを別のPRのブランチにする運用を、手作業の rebase で回している人

• AIコーディングエージェントで、前の変更に依存する変更を続けて作っている人

• 自前のツールやbot、ChatOpsでPRをマージしている人(スタックのマージには非同期のマージAPIが必要)

関係しない人

• GitHub Enterprise Serverだけを使っている人(2026年10月10日時点では「今後のリリースで対応予定」)

• フォークからPRを出す運用の人(フォークをまたぐスタックは不可)

• PRをGitHub Desktopだけで扱っている人(GitHub Desktopは非対応)

自分が当てはまるかの確認方法

gh stack 拡張の前提(GitHub CLI 2.90.0以降、Git 2.20以降、認証済み)を、次のコマンドで確認できます。

gh --version
git --version
gh auth status
gh extension list

gh extension list は、入っている拡張の一覧を出すコマンドです。gh stack 拡張がもう入っているかを確認できます。

Stacked pull requestsとは

公式ドキュメントでは、スタックは「同じリポジトリ内の2つ以上のプルリクエストで、それぞれが1つ下のプルリクエストの上に積まれたもの」と説明されています。

• 一番下のPRは、trunk(通常は main などのデフォルトブランチ。リリースブランチなども可)を向く

• その上のPRは、1つ下のPRのブランチを向く

• 各PRに表示される差分は、そのブランチと1つ下のブランチの差だけ

共有の型やDBスキーマのような土台の変更を下の層に、APIルートやUIのようにそれに依存するコードを上の層に置く、というのが基本の考え方です。ある層のコードが別の層に依存するなら、依存先は同じブランチか、それより下に置きます。バックエンドからフロントエンドへ移るときや、ブランチが大きくなりすぎたときが、新しい層を切る目安です。

スタックを使わない場合との違い

これまでも、PRのベースを別のPRのブランチにする運用自体はできました。ただ、下のPRに修正が入るたびに上のブランチを手で rebase する必要があり、ブランチ保護のルールやCIもデフォルトブランチを向いた一番下のPRにしか効かない、という問題がありました。スタックでは次のように扱われます。

• rebase: GitHubが自動で処理する。PRの画面からサーバー側でまとめて rebase するか、gh stack でローカルで行う。一番下のPRがマージされると、残りのブランチが rebase され、次のPRがベースブランチを向く

• ルール: スタック内のすべてのPRが、一番下のPRのベースブランチ(通常は main)のルールで評価される。CODEOWNERSの承認や必須のステータスチェックも、途中の層のPRに適用される

• CI: デフォルトブランチへのPRで走るチェックが、スタック内のすべてのPRで走る。GitHub Actionsのワークフローもそのまま使える

訳: CODEOWNERの承認などのブランチ保護ルールは、デフォルトブランチを直接向いていないスタック途中のPRも含め、スタック内のすべてのPRに適用されます。(GitHub Docs「About stacked pull requests」)

GAで追加・変更された点

10月6日のChangelogに挙がっている主な変更です。

• 「Rebase stack」をしても、変更のないコードへの承認は残る(古い承認を取り消す設定のリポジトリでも同様)

• rebase されたコミットは署名が保たれ、元の作者も保持される

• スタックはマージキューに1つのマージグループとして入る。マージコミット方式では、PRごとにマージコミットが作られる

• リポジトリのルールをバイパスできる権限があれば、スタックの一番下の未マージPRをバイパスでマージできる

• ベースブランチが削除されると、一番下のPRを閉じずに自動でリターゲットする

• スタックのauto-mergeは、今後数週間で順次提供

• PRのヘッダーとPR一覧にスタックの情報が表示される。Shift+J / Shift+K でスタック内のPRを移動できる

• pull_request webhookに stacked アクションが追加

• gh stack 拡張がGitのworktreeに対応し、初期化・チェックアウト・移動が速くなった

提供範囲は、github.comのすべてのプランです。GitHub Enterprise Serverは、今後のリリースで対応予定とされています(2026年10月10日時点)。

訳: Stacked pull requestsは、github.comのすべてのプランで利用でき、今後のGitHub Enterprise Serverのリリースに含まれる予定です。(GitHub Changelog「Stacked pull requests generally available」)

前提と制約

• スタック内のブランチは、すべて同じリポジトリにある必要がある。フォークをまたぐスタックは不可

• 一直線のブランチの連なりだけで、途中で枝分かれする構造は不可

• GitHub Desktopは非対応(Web、GitHub CLI、GitHub Mobile、REST / GraphQL API、webhookで扱える)

• リポジトリや組織で機能を有効にする設定は不要

gh stackで始める

Webの画面からも扱えますが、ブランチの作成から rebase、PRの作成まで一通り面倒を見てくれるのが、GitHub CLIの拡張 gh stack です。前提は、GitHub CLI 2.90.0以降、Git 2.20以降で、gh auth login で認証済みであることです。

1. 拡張を入れる

gh extension install github/gh-stack

Copilotなどのコーディングエージェントに使わせる場合は、スキルも用意されています。

gh skill install github/gh-stack

2. スタックを作り、層を積む

gh stack init
git add .
git commit -m "Auth middleware"

gh stack add api-routes
git add .
git commit -m "API routes"

gh stack init で最初のブランチ名を聞かれます。trunkはデフォルトブランチで、-b(--base)で別のブランチも指定できます。gh stack add は、今のスタックの一番上に新しいブランチを足して、そこに切り替えます。

ステージとコミットと層の追加を一度に行う書き方もあります。今のブランチにまだコミットがなければそこにコミットし、すでにコミットがあれば次の層のブランチを作ります。

gh stack add -Am "Auth middleware"
gh stack add -Am "API routes"

3. pushしてPRを作る

gh stack push
gh stack submit
gh stack view

gh stack submit で、各ブランチに正しいベースのPRが作られ、GitHub上でスタックとしてつながります。一番下は main を、それより上は1つ下のブランチを向くので、レビュアーにはその層の差分だけが見えます。gh stack view で、ブランチ、PRのリンクと状態、各ブランチの最新コミットを一覧できます。

よく使うコマンド

• gh stack sync: fetch、rebase、push、PRの状態の同期をまとめて行う

• gh stack rebase: origin から fetch して、スタック全体を順に rebase する。衝突したら --continue / --abort

• gh stack up / down / top / bottom: スタック内のブランチを移動する

• gh stack modify: 対話的な画面で、層の削除・統合・挿入・並べ替え・名前変更を行う

• gh stack merge <PR番号>: 指定したPRまでを、全部成功か全部失敗かでマージする。--squash などで方式を指定できる

• gh stack unstack: スタックを解除する(gh stack delete は別名)

並べ替えは gh stack modify でその場でできますが、Webの画面では一度スタックを解除して作り直す必要があります。

マージの考え方

• マージは下から順に。スタック全体を一度にマージする必要はない

• 一番上のPRをマージすると、スタック全体がマージされる

• 途中のPRをマージすると、それより下のPRも一緒にマージされる。上のPRは開いたまま残り、スタックのベースブランチを向くように自動で付け替わる

• マージ方式は、マージコミット、squash、rebase マージに対応。結果の履歴は、下から1つずつマージした場合と同じになる

• すべてのPRがマージされると、スタックは自動で閉じる。その後に gh stack submit した新しいブランチは、新しいスタックになる

訳: スタック全体を一度にマージする必要はありませんが、PRは下から順にマージしなければなりません。(GitHub Docs「About stacked pull requests」)

導入前に確認しておきたいこと

公式の導入ガイドでは、チームで使い始める前に次の点を見直すよう案内されています。

• マージ用のツール: スタックは従来のPRマージ用エンドポイントではマージできません。自前のツールやbot、ChatOpsでマージしている場合は、スタックと通常のPRの両方に対応する非同期のマージAPIに切り替えておく

• 集計やトラッキング: REST APIのPRのレスポンスに stack オブジェクトが入る(スタックでないPRでは null)。GET /repos/{owner}/{repo}/stacks でスタックの一覧を取れる

• CIの負荷: すべての層でCIが走るので、重いジョブは github.event.pull_request.stack を式の中で使って絞り込める

まとめ

• Stacked pull requestsは、大きな変更を依存順に積んだ小さなPRに分け、層ごとにレビューできる機能。2026年10月6日にGA

• rebaseはGitHubが自動で処理し、ブランチ保護・CODEOWNERS・CIはスタック内のすべてのPRに効く

• gh extension install github/gh-stack → init → add → push → submit が基本の流れ

• 同一リポジトリ・一直線の構造のみ。マージを自動化している場合は非同期マージAPIへの対応が必要

関連記事

• GitHubのSSHが10月14日から変わる。RSA鍵3072ビット必須とssh-rsa廃止で確認すること

• GitHub Actions × Claude APIで、pushのたびにコミット要約をSlackへ送る

出典(2026年10月10日に確認):

• GitHub Changelog「Stacked pull requests generally available」(2026年10月6日) https://github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available/

• GitHub Docs「Stacked pull requests」 https://docs.github.com/en/pull-requests/how-tos/stacked-pull-requests

• GitHub Docs「About stacked pull requests」 https://docs.github.com/en/pull-requests/get-started/about-stacked-prs

• GitHub Docs「Stacked PRs quickstart」 https://docs.github.com/en/pull-requests/get-started/stacked-prs-quickstart

• GitHub Docs「gh stack CLI commands」 https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands

• GitHub Docs「Roll out stacked PRs」 https://docs.github.com/en/pull-requests/tutorials/roll-out-stacked-prs

提供範囲やコマンドは今後も変わる可能性があるので、最新の内容は公式ドキュメントで確認してください。

開発ツールの仕様変更・提供終了の情報を毎朝お届けしています。見逃したくない方は、フォローしてください。