Evan Priestley built Phabricator's Differential review tool because he was tired of waiting. That's the whole origin story, in his own words: he was spending too much time blocked on code review, so he built a system where you didn't have to be. Stack your changes, get each one reviewed independently, keep moving. People who used it at Meta describe it the way people describe a good editor: once you've had it, going back to anything else feels like a regression.
That workflow has existed for over a decade. Graphite built a company on bringing it to GitHub, because GitHub itself never had it. Aviator did too. Sapling and git-branchless gave you a rougher, free version if you were willing to fight your own tooling a little. And on July 30, 2026, GitHub shipped stacked pull requests natively, in public preview, to every repository, for free, with a CLI extension called gh-stack and a skill package so Copilot and other agents can drive the workflow directly.
The interesting question isn't "does this work." It mostly does. The interesting question is what it means for a platform to absorb a pattern that an entire category of startups was built to sell, and whether the version that ships for free to a billion commits a year is actually the same thing as the version that a small, opinionated team spent years refining.
What actually ships
A stack, in GitHub's implementation, is an ordered chain of branches where the bottom one targets your trunk and each branch above targets the branch below it, not main directly. gh stack init starts the chain. gh stack add <branch> layers on the next piece of work. You write code and commit inside each layer like you always have. When you push, GitHub renders a stack map at the top of every PR in the chain, so a reviewer looking at layer three can see what layers one and two changed without leaving the page.
The mechanically satisfying part is the cascading operations. gh stack rebase rebases every branch onto the one below it in sequence, starting from main, and it turns on git rerere automatically so a conflict you resolve once doesn't have to be resolved again as it propagates upward. Merge the top ready PR and everything beneath it lands in one operation. Merge a partial stack, just the bottom layers, and the ones still open above automatically retarget and rebase onto the new base. None of this required custom tooling before. It required discipline, a lot of git rebase --onto, and the kind of muscle memory that only comes from doing it badly a few dozen times first.
Existing branch protections and required checks apply unchanged to every layer. That's a deliberate, sensible choice: GitHub isn't asking teams to trust a new trust model, it's applying the old one to a new shape of work.
The argument nobody quite settles
The Hacker News thread on the public preview launch ran to 516 points and 282 comments, and the split in it is worth sitting with, because it's not a split about execution quality. It's a split about whether the premise is coherent.
One side: "stacked diffs have existed at Meta for a decade, glad GitHub is joining." Vindication for a pattern that felt, for years, like something only large engineering orgs with custom internal tools got to have.
The other side, sharper: either your changes are independent, in which case you should just open separate PRs against main, or they're dependent, in which case reviewing them separately doesn't actually make sense, because a reviewer approving layer two is implicitly approving the assumptions baked into layer one, whether they've re-read it or not.
I don't think that second position is wrong. I think it's identifying a real seam in the whole pattern, one that Phabricator veterans have always had an answer for, which is: dependence isn't binary. Layer two can depend on layer one's interface without depending on its implementation. A reviewer can meaningfully approve "this login form correctly calls the auth function that layer one added" without re-litigating whether layer one's auth function is itself well written, because that was already reviewed on its own PR. The stack doesn't eliminate the dependency. It makes the dependency explicit and lets you review each side of it at the resolution where a human can actually hold it in their head. A 900-line PR asks a reviewer to hold interface and implementation and five unrelated concerns all at once. A stack asks them to hold one thing at a time, in order.
That's a real answer. It's just not a free one, and the "either/or" critique is right that it costs something: reviewer trust has to extend downward through the stack, and if a lower layer turns out to be wrong after the layer above it already merged, you're now unwinding two changes instead of one, with a live dependency between them.
The bug that undercuts the actual selling point
Here's the part that matters more than the philosophical argument, because it's not theoretical. A GitHub discussion thread on the gh-stack repository (issue 212, if you want to go read it yourself) documents that merging an entire stack in one operation breaks in a meaningful set of cases. The workaround is merging PRs one at a time, and if your repo requires reviews and uses squash-and-merge, each individual merge in that sequence can trigger a re-approval requirement on the PRs above it.
Sit with what that means. The single biggest advertised benefit of stacked PRs is "merge everything in one operation instead of doing it layer by layer with manual rebasing in between." If squash-merge repos with required reviews end up back in a one-at-a-time merge flow that re-triggers approvals, you have kept most of the review-splitting benefit and lost a meaningful chunk of the merge-automation benefit that was supposed to be the other half of the pitch. It's not a dealbreaker. It's a public-preview rough edge, and GitHub will likely tighten it. But it's a real gap between the changelog post and the current lived experience, and the byteiota writeup on this launch flagged the same category of issue independently: squash-merge and cascading rebase conflicts are exactly the unglamorous plumbing that Graphite has had years to harden, and a public preview hasn't had years yet.
Why the timing isn't a coincidence
TED's CTO, Andy Merryman, put the connection directly: AI made TED's developers dramatically more productive, and that productivity created a new bottleneck, because PRs were growing large enough that reviewers were struggling to keep up. Stacked PRs, in his framing, don't just make review faster, they make it more accurate, because dependency-ordered pieces let a reviewer evaluate each piece at the resolution it deserves instead of skimming a diff that outgrew what one person can hold in working memory.
That's the real thesis, and it's a good one, but it assumes the thing being split is human-shaped work that happens to be large. A lot of what's filling review queues right now isn't. It's agent output, generated at a pace and in a style no human authored, then handed over to be verified. Splitting a 900-line agent-generated PR into five 150-line agent-generated PRs doesn't make any of them more legible if the reviewer's actual problem was never diff size, it was unfamiliarity with logic they didn't write and don't have a mental model for. Stacking helps enormously when the bottleneck is "this is too much to hold in my head at once." It helps much less when the bottleneck is "I don't trust what generated this."
What this does to Graphite, and what it doesn't
GitHub shipping this natively, for free, on every repository, is a genuine threat to Graphite and Aviator's core pitch, in the same way Actions eventually made a lot of standalone CI platforms a much harder sell to a team already paying for GitHub. "Good enough and native" beats "better but external" for a large share of teams, especially ones that were never going to pay for a dedicated stacking tool in the first place and were just living with manual rebase pain instead.
But Graphite didn't spend years on this because the core idea is hard. It spent years on the edges: the CLI ergonomics, the automation around restacking after upstream changes, the visualization, the parts that don't show up in a changelog post but show up in a team's daily friction once they're doing this at scale. GitHub's version is genuinely good for a public preview. It is not, yet, obviously better than what a team already deep in Graphite's workflow has. The teams most likely to switch are the ones who never adopted a third-party tool at all, and those teams are exactly the ones GitHub's free, native version was built for.
Where I land
Stacked PRs are a real, overdue upgrade, not a magic fix. GitHub finally caught up to something Meta engineers have known for a decade, and the mechanics are good enough to use today. But a five-PR stack is not five independently-verified units of trust, and a smaller diff doesn't make an unfamiliar one legible. Those are different problems wearing the same symptom, and no chunking strategy, however well built, tells them apart for you.
