GitHub Stacked Pull Requests: A Developer's Guide

GitHub moved stacked pull requests into public preview on July 30, 2026, rolling the feature out to all repositories over the following days. A stacked pull request is one layer in an ordered series that each target the branch below them instead of the trunk, so a change that would have been one large diff becomes several small ones reviewers can approve and merge independently — and GitHub now tracks that series natively as a single Stack object with its own merge button.

What changes versus one giant PR

Before this release, breaking a large change into a review-friendly sequence meant either opening several disconnected pull requests and manually rebasing each one as the branch below it changed, or reaching for a third-party tool like Graphite or git-branchless to manage the chain outside GitHub. Stacked pull requests fold that workflow into GitHub itself:

• Each pull request in a stack shows a stack map at the top, so a reviewer looking at layer three can see how it fits into the full change without leaving the page.
• Existing branch protections, required checks and review rules apply to each layer exactly as they would to a standalone pull request.
• The whole stack — or any single layer inside it — can be merged in one operation, and GitHub automatically rebases the branches still above a merged layer instead of leaving that to the developer.

Mayank Saini, a connectivity engineer at WHOOP, put the before/after in GitHub's own announcement: "A big change used to mean one giant PR nobody wanted to review. Now it's a stack of small ones reviewers can actually follow, and the whole stack merges in one shot."

Setting up a stack with the CLI

Stacks are created and managed through gh-stack, an extension for the GitHub CLI (gh version 2.0 or later):

gh extension install github/gh-stack
 
gh stack init                # start tracking a stack from the current branch
# ... commit work on the first layer ...
gh stack add                 # create a new branch stacked on top
# ... commit work on the second layer ...
gh stack submit              # push every branch, open/update linked PRs

gh stack sync is the all-in-one command for keeping an existing stack current: it fetches, rebases every layer, force-pushes with a lease, and updates the linked pull requests on GitHub in a single call — the step that replaces manually rebasing layer two after layer one's diff changes. Stacks are also navigable directly from the terminal with gh stack up, down, top and bottom to move between layers, and reviewable through the GitHub.com UI, the GitHub mobile app, or a coding agent using the gh-stack skill (installed with gh skill install github/gh-stack) — the same extension mechanism that lets AI coding agents open and update multi-layer PRs without a human running the CLI commands by hand.

What's still rolling out

Two parts of the feature aren't fully live yet, and both matter before a team adopts stacks for its main workflow:

1. Merge queue support is rolling out progressively over the coming weeks, separately from the July 30 public preview. A repository that gates merges through a queue should verify stack support is active there before routing queue-required branches through a stack.
2. Public preview means the feature can still change based on feedback before general availability — GitHub has not published a GA date.

Why this matters for review throughput

The core problem stacked PRs solve isn't new — teams working on large features have split them into sequential branches for years, and tools like Graphite built businesses around making that sequence reviewable. What changes on July 30, 2026 is that the stack itself, the rebase-on-merge behavior, and the merge-everything-at-once action are now part of GitHub's own pull request model rather than a layer bolted on top of it. For a team that already writes large changes as a linear sequence of commits, the practical shift is smaller review latency per layer (a 200-line diff gets reviewed faster than a 2,000-line one) without the manual rebase tax that made splitting a change painful enough that most developers didn't bother.

Teams using npm's allowScripts allowlist or other reviewed, versioned CI gates should note that per-layer checks run on every pull request in a stack exactly as they do today — splitting a change into a stack doesn't change how many times CI runs, only how much of the diff a human has to hold in their head at once per review pass.