Introducing Stack Pull Request in GitHub

Big pull requests are painful. They take too long to review, mistakes slip through, and AI coding agents now make them even bigger. Stacked pull requests are GitHub's answer, and they entered public preview on July 30, 2026.

In this deck I explain what stacked PRs are: a chain of small PRs in one repository, where each PR targets the branch below it and the whole stack lands on main. I walk through the three steps - build the stack, review each layer on its own using the stack map, then merge one, some, or all of them while the PRs above are rebased and retargeted for you.

I also cover how your quality bar stays the same (branch protection and required checks still apply), where you can use this (github.com, GitHub CLI, mobile, and the Copilot app), and a case study of modernizing a 10-year-old React front end with stacked sessions instead of one 10,000-line PR.

Try it now: gh extension install github/gh-stack

Transcript

1. GITHUB · PUBLIC PREVIEW · 2026.07.30 Stacked Pull Requests 入門 大きな変更を、小さくレビューして、一気にマージする かめがわ かずし PR #3 feature C PR #2 feature B PR #1 feature A main base branch kkamegawa Microsoft MVP — Developer Technologies & Cloud Security 2026年7月31日 各 PR は 1 つ下の PR を “ターゲット” にする
2. This contents based on 2026/7/31 Images created by Adobe Firefly and Microsoft Copilot Gemini 3.1 w/ Nano Banana 2)
3. Who am I? personal: name: KAMEGAWA Kazushi(Last-First) alias: kkamegawa community: MVP: Microsoft MVP for Developer Technologies and Cloud Security Users Group: Team Foundation Server Users Group URL: https://dev.azure.com/tfsug/tfsuginfo Blog: URL: https://kkamegawa.hatenablog.jp devblog radio: https://devblog.connpass.com/
4. 課題 / WHY なぜ Stacked PR？ — 大きな PR の痛み 巨大な PR は、誰もレビューしたくない 1 手動でブランチ分割 → リベース地獄 2 AI で生産量が急増 → レビューが新たなボトルネックに 3 1 つの大きな PR はレビューに時間がかかり、精度も落ちる。見落としが増え、フィードバックが遅れる。 依存し合う変更を複数ブランチに分けると、手作業のリベースと追従を延々と続けることになる。 コーディングエージェントが大量の変更を生み、PR が肥大化。レビュアーが追いつかなくなる。 Stacked Pull Requests 03 / 08
5. 定義 / WHAT Stacked Pull Requests とは • 同じリポジトリ内で、順序づけられた PR のチェーン • 各 PR は「1 つ下の PR のブランチ」をターゲットにす る PR #3 feature C PR #2 feature B PR #1 feature A main base branch • チェーンは最終的に main へ着地する • 大きな変更を、焦点を絞った小さなレイヤーに分解でき る = 「1 つの巨大 PR」ではなく「小さな PR の積み重ね」 各 PR は 1 つ下の PR を “ターゲット” にする Stacked Pull Requests 04 / 08
6. 仕組み / HOW IT WORKS 3 ステップで動く 1 2 3 スタックを作る レイヤーごとに独立レビュ ー まとめて / 個別にマージ 最初のブランチと PR から始め、その 上に重ねていく。各 PR は 1 つ下のレ イヤーをターゲットにする。 その差分だけを確認。PR 上部の “stack map” で全体像を把握でき、チ ームで並行してレビューできる。 準備できた PR をマージすると下の未 マージ層も一括着地。一部だけの着地 も可能で、上の PR は自動で rebase & retarget。 gh extension install github/gh-stack Stacked Pull Requests review only this layer merge one, some, or all 05 / 08
7. メリット / BENEFITS Stacked PR で得られること Stacked Pull Requests 開発を止めない 品質を維持 短く焦点を絞った PR を並行レビュー。大きな機能 開発を止めずに進められる。 既存のブランチ保護・必須チェックがそのまま働き 、main を守る。 柔軟なマージ GitHub 標準機能 1 つ・一部・全部を、まとめて or 個別に着地。上 位 PR は自動で追従。 既存のレビュー・チェック・マージ要件がそのまま 動く。追加ツール不要。 06 / 08
8. 実例 / IN PRACTICE GitHub Copilot App × Stacked Sessions Stacked Sessions とは 同一リポジトリで、前のセッションを土台に積み上がる一連のタスク。 ① 現在の変更で PR を作成 ② その上に積む stacked session を生成（前の文脈を引き継ぎ、計画を立てて 承認後に実行） ③ 既存の作業に続く stacked PR を自動作成 CASE STUDY 10年物のフロントエンドをモダン化 • React 15 / Less / 旧 react-bootstrap の 古い構成 • スコープクリープ（1 万行の巨大 PR）を 回避 • react-bootstrap の置き換えを別レイヤー に分離 “セッションが連なるだけでなく、変更も連なる” Stacked Pull Requests • Plan モードで方針を決定し、スタックで安 全に出荷 07 / 08
9. まとめ & はじめ方 小さくレビュー、一括で着地 大きな変更を小さな PR に分解し、まとめて or 個別にマージ。 品質はそのまま 今すぐ試す $ gh extension install github/ghstack 既存のブランチ保護・チェック・レビューがそのまま機能。 Public Preview は全リポジトリへ順次展開中。 Merge queue 対応も順次ロールアウト。 どこからでも使える github.com / GitHub CLI / Mobile / Copilot（gh-stack skill）。 出典: github.blog「Stacked sessions and pull requests in the GitHub Copilot app」／「Stacked pull requests are now in public preview」(2026/7/30)
10. Stacked pull request こんなかんじ
11. reference 参考資料 Stacked pull requests are now in public preview - GitHub Changelog Stacked sessions and pull requests in the GitHub Copilot app The GitHub Blog Stacked pull requests - GitHub Docs Managing a merge queue - GitHub Docs