GitHub's Native Stacked PRs Are a Decade Overdue

GitHub flipped the switch today: stacked pull requests are in public preview for all repositories, three and a half months after the private preview opened in April. You can now build a chain of PRs where each layer targets the branch below it, review each layer as a focused diff, and either land the whole stack in one click or merge layers individually while GitHub rebases and retargets everything above automatically.

That last clause is the entire feature. Everything else — the stack map in the PR header, the optional CLI — is UI. The auto-rebase-and-retarget is the part that took a decade of third-party tools to approximate, and it's the part that makes this worth your attention.

The workflow Meta never gave back

Stacked changes aren't new; they're just new to GitHub. Phabricator, built at Facebook in 2007, made the stacked-diff workflow the default for a generation of Meta engineers, and Google's Gerrit has modeled changes as ordered, individually-reviewable commits since forever. When Phabricator's open-source development ended in 2021, its users scattered into the GitHub ecosystem and immediately hit the impedance mismatch: GitHub's unit of review is a branch, and branches that depend on other branches are a manual, error-prone mess. Merge the bottom PR and every PR above it shows a polluted diff until you hand-rebase the chain and force-push each branch.

The ex-Meta diaspora built an entire tool category to paper over this: Graphite (founded by former Meta engineers, with a stack-aware merge queue and paid plans at $20/user/month), Meta's own open-source ghstack, git-spice, spr. Every one of them is a client-side workaround fighting a server that doesn't understand stacks. GitHub understanding stacks natively — retargeting on merge, running CI per layer as if it targeted main, enforcing branch protections against the final target branch rather than the intermediate one — removes the fight at the source.

What you actually get

The mechanics, as shipped: each PR in a stack targets the branch of the PR below it, bottoming out at trunk. Reviewers see a stack map showing where each layer sits and review only that layer's diff. Merging the top PR merges everything below it bottom-up in one operation; merging a middle layer rebases and retargets the remainder. It works from the web UI, the API, the mobile app, and an optional CLI extension (gh extension install github/gh-stack) whose sync command cascades a rebase across the whole stack.

The CLI being optional matters more than it sounds. Graphite's biggest adoption blocker was always that the whole team had to buy into its client tooling for the workflow to hold together. Here, a teammate who's never heard of stacking can review and merge a layer from the web UI and nothing breaks. That's the difference between a workflow you can adopt unilaterally and one that needs a team migration.

GitHub is also explicitly pitching this at coding agents — the changelog calls out Copilot compatibility, and the CLI was designed with agents in mind. That's the right read of the moment. The teams drowning in review debt right now are the ones whose agents generate 2,000-line PRs; an agent that emits a stack of five focused layers instead is reviewable by humans in a way a monolithic diff never will be. GitHub cited research during the preview that PRs in the 200–400 line range had roughly 40% fewer defects and got approved about three times faster. Stacking is how you keep agent output inside that window without artificially slicing work.

Read the fine print before you migrate

Two caveats, one of them serious. During the private preview, InfoQ reported that squash and rebase merges broke the stack's commit-identity tracking — only standard merge commits worked reliably. Squash-merge is arguably the dominant merge strategy on GitHub, precisely because teams use it to compensate for messy PR histories. If that limitation survives into the public preview (GitHub's announcement doesn't address it head-on), a large fraction of teams can't adopt stacks without changing their merge policy first. Test this on a scratch repo before you change anything: build a three-layer stack, squash-merge the bottom, and see whether layer two's diff stays clean.

Second: merge queue support is still "rolling out progressively over coming weeks." If you run a busy monorepo, the merge queue is exactly where stacks pay off — Graphite's stack-aware queue is its marquee feature — so the preview is arguably launching without its most valuable integration. Wait for it.

And keep stacks shallow. Practitioners in the preview converged on three to four layers as the practical ceiling; beyond that, cascade rebase conflicts and reviewer context-switching eat the gains. A stack is a narrative — setup, refactor, feature, cleanup — not a place to park every commit you've ever made.

Who this squeezes

This is a genuine shift, not a hype cycle — it's GitHub absorbing a workflow that Meta and Google validated internally for fifteen years, and the mixed Hacker News reception ("git can already do this") misses that the pain was never git, it was GitHub's server-side review model. But it's also a textbook platform-absorbs-ecosystem move. ghstack, git-spice, and spr exist almost entirely to simulate this feature; their reason to exist is now a preview toggle. Graphite has more altitude — its merge queue, review UX, and its pivot toward AI-assisted review give it a product beyond stack bookkeeping — but its free-tier funnel just got a lot narrower when the platform bundled the core workflow for nothing.

My advice: if you're on Graphite and happy, nothing forces a move today, especially pre-merge-queue. If you've been stack-curious but wouldn't adopt third-party tooling, this is the moment — start with one feature, one three-layer stack, standard merge commits. And if your team runs squash-merge-everything, hold until you've verified GitHub has solved identity tracking for your merge strategy. The workflow is proven. The implementation is three months old. Treat it accordingly.