How to Use GitHub Stacked Pull Requests in 2026: A Practical Guide for Builders and AI Agents

GitHub stacked pull requests, which entered public preview on July 30, 2026, break a large code change into an ordered chain of small, dependent PRs that reviewers can review in parallel and you can merge in a single click. For builders shipping big features (or letting AI agents run for hours at a time), stacks solve the two complaints that derail most reviews: PRs too large to read, and "rebase hell" while you wait for the layer below to land. The feature is built into GitHub.com, the GitHub CLI via the official gh-stack extension, the mobile app, and coding agents like GitHub Copilot through a dedicated gh-stack skill. It does not change Git itself — it changes how GitHub tracks and merges the dependency chain you already could build by hand.

Last verified: 2026-08-05 · Pricing/limits change often — last checked 2026-08-05. TL;DR:

• GitHub stacked PRs are in public preview as of July 30, 2026, rolling out to all repositories over the following days (GitHub Changelog).
• Install the official CLI extension: gh extension install github/gh-stack (github/gh-stack).
• Each PR targets the branch below it, so reviewers see only that layer's diff; branch protections and required checks still govern main.
• Merge the top ready PR to land it and every settled layer beneath it in one operation; or merge part of a stack and let GitHub auto-rebase the rest.
• Best for: large multi-layer features, AI-agent long runs, and teams whose review bottleneck is PR size — not for tiny one-off changes.

What are stacked pull requests, and how do they differ from regular PRs?

Stacked pull requests are an ordered series of PRs where each PR represents one focused layer of a larger change, and each PR's base is the branch of the PR below it rather than main. In a three-layer stack the bottom branch targets main, the middle targets the bottom branch, and the top targets the middle — so every reviewer sees only the diff for their layer, not the whole change piled into one PR (GitHub Docs — Stacked pull requests).

Nothing changes inside Git itself. You could always daisy-chain branches in plain Git: open PR #1 to main, then PR #2 with its base set to PR #1's branch, and so on. What's new is that GitHub now recognises the chain, renders a stack map at the top of each PR showing where it sits in the whole change, lets reviewers work on different layers in parallel, and lets you merge the latest ready PR to land it and every unmerged layer below it in one operation (GitHub Changelog, July 30 2026). Without stacks, doing this by hand meant waiting for PR #1 to merge, rebasing PR #2 onto main, re-targeting PR #3, and repeating — the "rebase hell" that pushed teams toward third-party tools like Graphite and Sapling for years.

When should you use stacked PRs (and when should you skip them)?

Stacked PRs pay off when a change has natural layers that depend on each other and would otherwise form one giant PR nobody wants to review. They are not worth the overhead for a one-file fix or an unrelated bundle of changes.

Use stacks when:

• A feature spans multiple layers — schema, backend, API, frontend, tests — and you want each reviewed separately.
• An AI coding agent is running autonomously and producing many related commits you want packaged as logical units rather than one mega-PR (the changelog explicitly calls out GitHub Copilot with the gh-stack skill for this).
• Your team's bottleneck is review throughput, not code authoring — TED's CTO Andy Merryman, quoted in the launch announcement, said AI made TED's developers more productive but "PRs were growing large enough that reviewers were struggling," and stacks let review happen "in smaller logical chunks — not just faster PR reviews, but more accurate ones" (GitHub Changelog).

Skip stacks when:

• The change is small enough to read in one sitting — the stack adds tooling overhead for no review benefit.
• The "layers" don't actually depend on each other — open independent PRs to main instead.
• Your CI can't run meaningfully per-layer (see the section on CI below).

How do you create a stacked pull request with the GitHub CLI?

The fastest path is the official gh-stack CLI extension. Prerequisite: GitHub CLI gh v2.0 or newer (github/gh-stack). One-time install:

gh extension install github/gh-stack

Then a typical three-layer stack for a feature that adds a database table, an API endpoint that uses it, and a frontend that consumes the endpoint:

1. Initialise the stack and create the first (bottom) branch. This creates and checks out the first branch on top of your trunk (usually main):

   gh stack init setup-database
   

2. Write code for layer one, then commit it (standard Git):

   git add .
   git commit -m "Add payments table and migration"
   

3. Add the next layer on top of the current one. gh stack add creates a new branch that builds on the branch you're currently on:

   gh stack add api-endpoints
   

4. Write and commit code for layer two, then repeat gh stack add <name> for each subsequent layer (frontend, tests, etc.):

   git add .
   git commit -m "Add POST /payments endpoint"
   gh stack add setup-frontend
   git add .
   git commit -m "Wire payments form to the API"
   

5. Push everything and create the PRs in one command. gh stack submit pushes all branches and opens one PR per layer, automatically setting each PR's base to the branch below it so the diffs stay clean. It opens an interactive editor where you can fill in titles and descriptions per PR (or pass --auto to skip the editor and use auto-generated titles):

   gh stack submit
   # or, non-interactive:
   gh stack submit --auto --open
   

Each PR is created with the correct base branch, so reviewers see only that layer's diff, and the PRs are automatically linked together as a stack on GitHub (GitHub Docs — Creating stacked pull requests).

How do you create a stack from the GitHub website (no CLI)?

You can build a stack without the CLI by setting the base branch of each PR to the branch of the PR below it:

1. Create the first PR as you normally would, with its base targeting main.
2. Create the next PR and set its base branch to the first PR's head branch, then select the Create stack option to link the two PRs together.
3. Repeat for each additional PR, targeting the branch of the PR before it.

If you already have open PRs whose branches line up — each PR's base branch is the head branch of the PR below it — GitHub shows a recommendation banner on the eligible PRs offering to turn them into a stack with one click (GitHub Docs).

How do you review and merge a stack?

Reviewing in parallel. Open any PR in the stack to review only that layer's diff. A stack map at the top of the PR shows where the reviewed change fits into the larger work, and teammates can review different layers simultaneously without blocking work further up the stack.

Merging in one click. Merge the latest "ready" PR to land it and every unmerged layer below it in a single operation. To land only part of a stack instead, merge one or more lower layers; the PRs above stay open and automatically rebase and retarget onto the new base. Existing branch protections and required checks still govern what reaches main — stacks do not bypass them (GitHub Changelog).

From the CLI, gh stack merge merges one or multiple stacked PRs as an all-or-nothing operation: if any PR can't merge, none of them do. If the stack's base uses a merge queue, the stack is added to the queue and the queue chooses the merge method. The extension's README is explicit that bypassing merge requirements is not supported (github/gh-stack).

What does the full gh stack command set look like?

For automation and scripts, here is the practical command surface (see the gh-stack README and the Stacked PRs CLI commands reference for the full list, flags, and exit codes):

Command	What it does	Common flags
gh stack init <name>	Start a new stack; checks out the first branch on the trunk	-b, --base <branch> (trunk)
gh stack add <name>	Add a new branch on top of the current stack	-A (stage all), -m "<msg>" (commit)
gh stack submit	Push branches and create/update PRs + the stack on GitHub	--auto (no editor), --open (mark ready)
gh stack sync	Fetch, rebase, push, and sync PR state in one command	--prune (delete merged local branches)
gh stack rebase	Cascading rebase across the stack from trunk upward	--downstack, --upstack, --continue, --abort
gh stack modify	Terminal UI to drop, fold, insert, rename, reorder branches	Interactive
gh stack merge	Merge one or more stacked PRs (all-or-nothing)	--squash/--merge/--rebase, -y
gh stack checkout	Check out a stack by number, PR number, URL, or branch	Bare numbers try stack/PR ID first
gh stack link	Link existing PRs into a stack without local tracking	For jj / Sapling / git-town users
gh stack view	Show the current stack: branches, ordering, PR links	—

A gh skill install github/gh-stack step also exists so coding agents (like GitHub Copilot) can call the same commands from inside their tool loop instead of a shell — the launch announcement explicitly mentions Copilot with the gh-stack skill as a supported surface (GitHub Changelog).

Stacked PRs vs Graphite, Sapling, and git-branchless — which should you pick?

Stacked-diff workflows predate GitHub's native feature by years. Here's how the options compare for a builder choosing today:

Tool	What it is	Best for	Trade-off
GitHub Stacked PRs (gh-stack)	Native GitHub feature, public preview since July 30, 2026	Teams already on GitHub who want stacks without a new tool	Public preview — behaviour may change before GA; merge-queue support rolling out progressively
Graphite	Third-party stacked-diff product with its own dashboard	Teams that want richer analytics and a polished stacking UX on top of GitHub	Separate service, separate billing, extra surface area
Sapling	Meta's open-source version control with native stacked changes	Teams that want stacking baked into the VCS itself, not bolted on	A different VCS workflow — larger investment than a Git extension
git-branchless	Git extension for stacked-branch workflows in plain Git	Developers who want stacking inside Git without leaving the standard CLI	You bolt the GitHub-side tracking on yourself; less turn-key than gh-stack

For most teams already on GitHub, the native gh-stack path is now the lowest-friction option. The gh stack link command also means you can keep using jj, Sapling, or git-town locally and still link the resulting PRs into a native GitHub stack (github/gh-stack).

What does this mean for you?

For builders and small teams using AI agents, the headline is this: stacks turn a multi-hour agent run from "one giant unreviewable PR" into a chain of small, focused diffs that still merge in one click. When an agent — whether GitHub Copilot with the gh-stack skill or another coding agent — produces 20 commits across schema, API, and UI, you can have it package them as a stack and then review each layer the same way you'd review a hand-written PR. That's the workflow direction the launch announcement points at, and it lines up with what teams like Next.js and WHOOP, quoted in the changelog, are already doing.

For reviewers, stacks shrink the unit of review. The Next.js lead Tim Neutkens is quoted saying the team has used stacked PRs "for the past few months" to "introduce smaller individual changes while shipping larger features, making it easier to review PRs" (GitHub Changelog). Less context-switching, fewer "I'll get to that 800-line PR on Friday" delays.

For teams evaluating CI: run your required checks per layer the same way you would per PR — each PR in a stack is a normal PR with its own diff and CI rules. The main new consideration is partial merges: when you merge a lower layer and the upper PRs auto-rebase, your CI runs again on the rebased diffs. Plan for that capacity. Also note that when to use AI coding agents like Claude Code or Codex in parallel with stacks is a natural follow-up — see our guide to parallelising AI work with subagents and the multi-agent AI coding comparison for how to chunk agent output.

For solo builders with one-person repos: try a two-layer stack on your next non-trivial change before committing to stacks as a default workflow. If you want a CLI-first coding setup more broadly, our free vibe coding tools roundup and the two-model Claude Code + Codex CLI setup cover the wider stack.

FAQ

Q: What exactly is a stacked pull request on GitHub? A: A stacked PR is one PR in an ordered chain where each PR targets the branch of the PR below it (the bottom targets main). Each PR holds one focused layer of a larger change, so reviewers see only that layer's diff. GitHub's native stacked-PR feature has been in public preview since July 30, 2026 (GitHub Changelog).

Q: Do stacked PRs require the GitHub CLI? A: No. You can build a stack purely on GitHub.com by setting each PR's base branch to the branch of the PR below it and selecting "Create stack." The gh-stack CLI extension (gh extension install github/gh-stack) just automates the branch and PR mechanics (GitHub Docs).

Q: Does merging a stack bypass branch protections? A: No. Existing branch protections, required reviews, and required checks continue to govern what reaches main. The gh-stack extension explicitly does not support bypassing merge requirements (github/gh-stack).

Q: Can I merge only part of a stack? A: Yes. Merge one or more lower layers and the open PRs above automatically rebase and retarget onto the new base. Merging the latest "ready" PR lands it and every settled layer below it in one operation (GitHub Changelog).

Q: Is GitHub stacked PRs generally available yet? A: No — it is in public preview as of July 30, 2026, rolling out to all repositories over the following days. Merge-queue support for stacks is rolling out progressively over the following weeks. There is no public GA date yet (behaviour may change before GA) (GitHub Changelog).

Q: Does GitHub Copilot / AI coding agents support stacked PRs? A: Yes. The launch names GitHub Copilot using a gh-stack skill as a supported surface, so an agent can decompose its own changes into stack layers. gh skill install github/gh-stack installs the skill for agents (GitHub Changelog).

Sources

• GitHub Changelog — "Stacked pull requests are now in public preview" (July 30, 2026): https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
• GitHub Docs — Stacked pull requests (overview): https://docs.github.com/en/pull-requests/how-tos/stacked-pull-requests
• GitHub Docs — Creating stacked pull requests (quickstart): https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/creating-stacked-pull-requests
• GitHub Docs — Stacked pull requests CLI commands (reference): https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands
• github/gh-stack — official CLI extension and agent skill repository (MIT, Go, requires gh v2.0+): https://github.com/github/gh-stack

Updates & Corrections

• 2026-08-05 — Initial publication. Stacked PRs in public preview as of July 30, 2026; merge-queue support still rolling out progressively.