GitHub switched on stacked pull requests in public preview on July 30, 2026, and it is rolling out to every repository over the following days. The feature splits one large change into an ordered series of small pull requests, each targeting the layer beneath it. It also handles the part that made stacking miserable on GitHub until now: merge a PR in the middle of a stack and GitHub rebases and retargets every PR above it automatically.

That second sentence is the actual news. Stacking as a practice is not new. Google built Gerrit around per-commit review back in 2008, Facebook built Differential on the same idea, and a small industry has spent the last several years bolting the workflow onto GitHub from the outside. What none of those tools could do from the outside was teach GitHub itself that your eight branches are one piece of work.

RelatedZig 0.16 rebuilds async I/O to end function coloring

One large pull request versus a stack of four dependent pull requests On the left, a single large pull request targets main as one block. On the right, the same work is split into four small pull requests, each targeting the one below it, with the bottom layer targeting main. THE SAME CHANGE, TWO SHAPES Before: one blocking PR +912 / -244 14 files, 1 reviewer reviewed all at once main After: four reviewable layers 4 UI wiring +118 3 API handler +203 2 Schema migration +341 1 Rename + types +250 main genztech.blog
Fig 1 A stack is the same diff, cut along review boundaries. Each layer targets the one below it, and only the bottom layer targets main.

What actually ships in the preview?

The mechanics are deliberately unexciting, which is the right call for something that touches every repository:

  • Four ways to build a stack. A CLI extension installed with gh extension install github/gh-stack, the github.com web UI, the GitHub mobile app, and coding agents including GitHub Copilot.
  • A stack map. Every PR in a stack shows where it sits in the larger change, so a reviewer looking at layer three knows what landed underneath it.
  • Automatic rebase and retarget on merge. Land any layer and the PRs above it move to follow, without a human running git rebase --onto four times and force-pushing.
  • Merge whole or piecemeal. You can land a stack in one action or let layers go in one at a time as they get approved.
  • Existing rules still apply. Branch protections, required checks and review requirements govern what reaches main exactly as before. Merge queue support is arriving on a slower rollout over the coming weeks.

Why does automatic retargeting matter this much?

Because it is the only part that was genuinely hard. Anyone can open five PRs that point at each other. The pain starts the moment one of them merges or picks up a review comment. Every branch above it now sits on a stale base, so you rebase the chain, force-push each branch, and watch GitHub either lose your review comments or mark files as changed that you never touched. Do that twice a day and stacking costs more than it saves.

Getting this right requires knowing that the branches are related, which is state GitHub never stored. Third-party tools had to keep that graph in their own database and reconcile it against GitHub's, which is why they needed an account, a bot user, and write access to your repositories. Moving the graph into GitHub deletes that entire category of problem.

How does it compare to Graphite, Sapling and Gerrit?

GitHub nativeGraphiteSaplingGerritPlain git
Where the stack graph livesIn GitHubThird-party serviceLocal clientIts own serverIn your head
Auto-rebase on mergeYesYesYesYesManual
Extra account or installCLI extension onlyAccount + repo accessNew client (sl)Separate serverNone
Review happens inGitHub PRsGraphite web UIReviewStackGerrit UIGitHub PRs
Honors your branch protectionsNativelyVia integrationVia GitHubOwn rulesYes
Stack-aware merge queueRolling outYesNoYesNo

Where did stacking come from?

  1. 2008Google open-sources Gerrit Review is per-commit by default, so stacking is not a workflow you adopt, it is the only workflow.
  2. 2011Facebook open-sources Phabricator Differential and the arc CLI put the phrase "stacked diffs" into general circulation.
  3. 2021Phabricator goes unmaintained Teams that built their review culture on it start rebuilding the workflow on top of GitHub.
  4. 2022Meta open-sources Sapling A Git-compatible client with stacking as a first-class concept, plus the ReviewStack UI.
  5. Jul 30, 2026GitHub ships stacking natively Public preview, rolling out to all repositories, with agents able to create stacks directly.
  6. Coming weeksMerge queue support The piece that decides whether large monorepos can actually adopt this.

Who does this actually help?

Two groups, and they are not the ones you would guess. The first is reviewers, not authors. A 900-line PR does not get reviewed, it gets approved. Splitting the rename from the migration from the handler means the person reviewing the migration is looking at 341 lines of the thing they actually understand.

The second is coding agents, and GitHub is not being subtle about it. An agent that produces a large change has the same review problem a human does, except worse, because nobody wants to read 900 lines an agent wrote. Letting the agent emit a stack turns one unreviewable artifact into four decisions a human can actually make. That is a more interesting answer to the AI code review problem than another summarization tool.

What it means for the market

Graphite is the obvious exposure. Its core product is stacking on GitHub plus a stack-aware merge queue and review inbox, and GitHub just made half of that a platform feature that costs nothing and needs no repo access. The historical pattern is not fatal but it is unkind: platform-native versions rarely match the specialist on depth, and they do not have to, because free and already-installed beats better for most teams. The surviving move is the one Graphite has been making anyway, pushing up into review analytics and agent workflows where GitHub is not yet competing.

RelatedCodeberg Bans Projects Mostly Written by Generative AI

For Microsoft, this is small revenue and large retention. Stacking was one of the few concrete reasons a sophisticated engineering org would route its review flow through something other than GitHub. The signal for investors is not a new line item, it is one fewer wedge for anyone trying to pull developer workflow off the platform.

What to watch · next two quarters
  • Merge queue timing. Until stack-aware merge queues land broadly, teams with heavy CI on main cannot really use this. That rollout is the adoption gate, not the preview.
  • Whether agents default to stacking. If Copilot starts emitting stacks instead of monolithic PRs by default, review load per agent change drops sharply and this becomes the more important half of the feature.
  • Conflict behavior under load. Auto-rebase is easy when layers touch different files. The real test is a stack where layer two and layer four both edit the same function.
  • Graphite's response. Watch whether it leans into merge queue depth and review analytics or contests the base workflow head-on.

Our take

This is a good feature shipped about five years late, and the delay is the interesting part. Stacking was never a hard technical problem. It was a hard product problem, because GitHub's entire mental model is that a pull request is a branch and a branch is independent. Admitting that real changes come in dependent chains meant contradicting the abstraction the product was built on, and platforms are slow to do that.

What finally forced it was probably not developer demand, which has been loud and ignored for years. It was agents. Once machines started producing large diffs at volume, the review bottleneck stopped being an annoyance and became the constraint on the whole pitch. Stacking is the cheapest available fix. Treat the timing as a signal about where GitHub thinks the pressure is coming from.

Practical advice: install the CLI extension, use it on one genuinely large change, and pay attention to what happens when you get review comments on layer two. That single interaction will tell you more about whether this is production-ready than the entire preview announcement.

Primary sources

Original analysis by GenZTech, built from GitHub's stacked pull requests changelog published July 30, 2026.