GitHub's Native Stacked PRs End the Third-Party Era

GitHub shipped stacked pull requests into public preview on July 30, rolling out to all repositories over the coming days with no waitlist. You install a CLI extension (gh extension install github/gh-stack), split a big change into an ordered chain of small PRs where each one targets the branch below it, and GitHub handles the part that's always been miserable: when a bottom PR merges, everything above it automatically rebases and retargets — server-side.

That last clause is the story. Everything else about stacking has existed for fifteen years. What GitHub just did is absorb it into the platform where the network effects live.

A decade of workarounds finally lands upstream

Stacked changes aren't new; they're older than the pull request model itself. Gerrit has treated a chain of dependent commits as first-class reviewable units since 2008, and Meta's internal Phabricator workflow made "stacked diffs" the default way thousands of engineers ship. What was new — and broken — was doing this on GitHub, where the PR model assumes one branch, one review, one merge.

So an entire cottage industry grew in the gap. ghstack came out of the PyTorch world to script the branch juggling. Meta open-sourced Sapling with stacking baked into the source control layer. Jujutsu rethought the problem with stable change IDs. And Graphite built a venture-backed company largely on making stacked PRs tolerable on GitHub, complete with its own CLI and review UI.

Every one of these tools shared a fatal adoption problem: they fixed the author's experience but not the reviewer's. You could convince yourself to learn gt or ghstack; convincing your whole team to review through a third-party lens — or to mentally reconstruct a dependency chain from five PRs titled "part 3/5" — was the actual barrier. Stacking only pays off when the reviewers play along, and reviewers live on github.com.

GitHub's version puts a stack map at the top of every PR in the chain, in the native interface, with zero installs on the reviewer side. That's the whole ballgame. The author-side CLI is explicitly optional; you can manage stacks through the UI, the REST and GraphQL APIs, or plain git. Webhooks now carry a stack object, which matters if you build tooling — your bots and dashboards can finally see chain structure instead of inferring it from branch-naming conventions.

What it actually does well

The mechanics are more complete than a typical GitHub preview. All three merge methods are supported — merge commit, rebase, and notably squash, which is precisely where local-first tools historically fell apart, because squashing rewrites the commits the rest of the stack was built on. GitHub can handle that mapping server-side, since it performs the merge and the cascading rebase in one motion. You can land one layer, a partial range, or the whole stack in a click, and merge queue support is rolling out over the coming weeks.

Branch protections apply per layer, including CODEOWNERS approvals on mid-stack PRs, and CI that would trigger on the trunk runs for every PR in the stack. That's the correct design — each layer is independently landable, so each layer must independently pass the bar.

The workflow itself is four commands deep: gs init to start a stack, gs add for each layer, gs push, and gs submit to open the chain of PRs with bases wired correctly.

The sharp edges are real

Three caveats before you migrate the team.

First, the review-stability problem isn't solved, just relocated. Stacks live on force-pushed branches, and GitHub still anchors review comments to commits rather than to a stable change identity the way Gerrit and Jujutsu do. When a mid-stack edit cascades rebases through five layers, expect some outdated-comment archaeology. This is the deepest design gap between GitHub's approach and the systems that inspired it, and it won't close without rethinking how reviews attach to changes.

Second, CI cost multiplies. A five-layer stack means five PRs running checks, and every cascading rebase re-triggers builds up the chain. On a per-minute CI plan, stacking a refactor that used to be one PR can plausibly triple your spend for that change. Budget for it, or gate expensive suites to the bottom layer and the merge queue.

Third, cross-fork stacks aren't supported — all branches must live in the same repository — and GitHub Desktop doesn't support the feature at all. That makes this a feature for teams with write access to a shared repo, which is to say: this is a corporate workflow feature. Drive-by open source contributors gain nothing yet.

Winners, losers, and the Graphite question

For teams, this is a genuine shift, not a marketing preview. The pattern it enables — small, focused, independently-reviewable changes that don't serialize behind each other — is one of the few workflow changes with a strong track record from Google and Meta, and the reason most GitHub shops never adopted it was tooling friction that just evaporated. If your team routinely ships 800-line PRs because splitting them meant a week of "waiting on the first PR to merge," you should be trialing this now. It's also well-timed for AI-assisted development, where agents happily generate sprawling diffs that nobody can responsibly review as a single unit.

Graphite is the obvious casualty of the classic platform pattern: build a product in a platform's gap, prove the demand, watch the platform absorb it. Its core stacking workflow is now a free native feature. Graphite retains real advantages — years of edge-case hardening, multi-platform reach, and a head start on AI review with Diamond — but "stacking for GitHub" as a standalone value proposition just died. Expect the same squeeze on ghstack and the rest of the ecosystem, which will survive mostly where teams have already built muscle memory around them.

The preview label deserves one honest caveat: merge queue integration is still landing progressively, and the force-push review UX is unproven at scale. But the architecture — server-side retargeting, API-first, protections enforced per layer — is the right one. This is the rare GitHub feature that changes how teams should work, not just how the UI looks.