GitHubは2026年7月30日、大規模なコード変更を、依存関係のある小さなプルリクエスト
- Stacked pull requests are now in public preview - GitHub Changelog
- About stacked pull requests - GitHub Docs
- Stacked sessions and pull requests in the GitHub Copilot app - The GitHub Blog
Exciting day! 🥞 Stacked PRs are in public preview on GitHub, built by my team with many partner teams helping across surfaces: https://
— David Poll (@depoll) July 30, 2026t. co/ BZteFv8qLa
Stacked pull requestsとは
Stacked pull requestsでは、同じリポジトリ内にある2件以上のPRを順序付きの
既存の大きなPRを自動で分割するのではなく、作成者が変更内容を依存関係に沿って複数のブランチへ分ける。最下層のPRは通常mainなどの基準ブランチをマージ先とし、上層のPRは一つ下のPRのブランチをマージ先とする。
たとえば、3件のPRを積み重ねた場合、ブランチとマージ先の関係は次のようになる。
┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top
┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
┌── feat/auth-layer → PR #1 (base: main) ← bottom
main (default base branch)
共通の型やデータベーススキーマなどの基盤となる変更を下層に置き、それに依存するAPIやUIの変更を上層へ重ねる。GitHubのPR画面には、スタック全体と各PRの状態を一覧できるマップが表示され、レビュー担当者はPRごとにその層だけの差分を確認できる。
スタックを構成するPRでも、既存のレビューやマージ要件が引き続き機能する。最下層のPRのマージ先となるブランチmain）
途中のPRをマージすると、そのPRと下層のPRが最下層から順にマージされ、上層の未マージPRは開いたまま残る。最上層のPRをマージ対象に選べば、スタック全体をまとめてマージできる。GitHubは残ったブランチを自動でリベースし、最下層となったPRのマージ先をmainなどの基準ブランチへ付け替える。必要なチェックを確認しながらPRを順番にマージする
Web、CLI、モバイル、APIに対応
Stacked pull requestsはGitHubのWebサイト、GitHub CLI、GitHub Mobileで利用できる。GitHub CLIでは、次のコマンドでgh stack拡張機能をインストールできる。
gh extension install github/gh-stack
この拡張機能は、スタックの作成やPRの追加、送信、同期、リベース、マージなどを扱う。スタックを構成するブランチは同じリポジトリ内に置く必要があり、フォークをまたぐスタックとGitHub Desktopには対応していない。
gh-stackリポジトリには、この拡張機能をAIコーディングエージェントから操作するためのgh stack view --jsonを使うとの指示が記載されている。GitHub CLIでは次のコマンドでSkillをインストールできる。
gh skill install github/gh-stack
gh skill install github/
— GitHub (@github) July 30, 2026gh-stack 🥞🥞🥞
CLIでは、4月のプライベートプレビュー以降、利用できる操作が増えた。現在は、gh stack modifyで対話画面を開き、スタック途中へのブランチ挿入や順序変更を行える。また、選択したブランチのコミットを上下の隣接ブランチへ取り込むfoldや、ローカルブランチとPRを残したまま、そのブランチとコミットをスタックから外すdropにも対応する。
既存ブランチもgh stack initの引数にすると自動で取り込まれる[2]。
独自ツールや自動化処理からは、Webhooksのほか、REST APIとGraphQL APIを利用できる。REST APIはスタックの作成や変更、GraphQL APIは読み取りに対応する。API経由でPRをマージする既存ツールは、スタック向けの新しいマージAPIへの対応が必要になる。
GitHub Copilotアプリでは作業セッションも積み重ねる
GitHubが同日ブログに公開した事例では、GitHub Copilotアプリで古いコードベースの改修を複数の
具体的には、先行セッションで進めたフロントエンドのスタイル刷新をPRにしたうえで、その変更を土台とする別のセッションを開始し、react-bootstrapの削除を別のPRにした。AIによるコード生成で変更範囲が大きくなりやすい場面でも、一つの巨大なPRへまとめず、依存関係を保ったまま作業とレビューの単位を小さくする例として紹介している。
gh stackでスタックの作成からPRの公開までを試す
GitHub CLIのgh stack拡張機能
スタックを作成して構成を確認
gh stack init --base main feat/を実行すると、同じ競合の解決内容を再利用するGitのrerere機能を有効にするか確認された。今回は有効にして、mainを基準とする最下層のブランチfeat/を作成した。続けてgh stack addでfeat/とfeat/を積み重ね、3層のスタックを作成した。
mainの上にfeat/auth-layer、feat/api-endpoints、feat/frontendを積み重ねたgh stack viewを実行すると、スタックを構成するブランチとそれぞれのコミット数がツリー形式で表示される。画面上では、mainに近い最下層からfeat/、feat/、feat/の順に並んでいることを確認できる。
gh stack viewでは、現在のブランチとスタック全体の構成を一覧できるブランチを挿入して順序を変更
gh stack modifyを実行すると、スタックの構成を対話形式で変更する画面が開く。右上には、ブランチの挿入、名前変更、順序変更などに使うキーが表示される。
gh stack modifyの画面では、スタックの構成と利用できる操作を確認できるまず、feat/を選択してIキーを押し、その上へfeat/を挿入した。変更はすぐには適用されず、未適用の変更として緑色で表示されるため、挿入位置を確認してから反映できる。
feat/testsをfeat/frontendとfeat/api-endpointsの間へ挿入した状態続けてfeat/を選択し、Shift+↑で1層上へ動かすと、feat/が最上層へ、feat/がその一つ下へ移った。移動した2本のブランチは紫色で示され、画面下部には未適用の変更が2件あることも表示された。
Ctrl+Sで変更を適用すると、必要なブランチが自動でリベースされた。再度gh stack view --shortを実行すると、feat/、feat/、feat/、feat/の順に並んだ4層のスタックを確認できた。
feat/testsがスタックの最上層になった4件のPRをまとめて作成
gh stack submitを実行すると、スタック内の各ブランチから作成するPRをまとめて編集する画面が開く。左側で対象のブランチを選び、右側でPRのタイトルと説明、ReadyまたはDraftの状態を指定できる。
gh stack submitでは、スタック全体を見ながらPRごとの内容を編集できる最初に画面を開いた時点では、途中で挿入したfeat/に固有のコミットがなかったため、いったん送信を中止して空コミットを追加した。再度gh stack submitを実行すると、4本のブランチがプッシュされ、4件のPR
GitHub上でスタックを確認
GitHubのPR一覧では、各PRにスタック内の位置が表示される。今回作成した4件では、最下層の1/、最上層の4/が付いている。
個別のPR画面からスタックのマップを開くと、基準ブランチのmainと4件のPRが縦につながって表示される。feat/になっていることも、PR上部の表示から確認できる。
スタック途中の
CLIで構成したブランチの順序が、各PRのマージ先とGitHub上のスタック表示に反映されることを確認できた。