GitHub finally ships stacked PRs — a decade after Phabricator

What happened

GitHub flipped stacked pull requests into public preview today. The feature lets you mark a PR as depending on another PR in the same repo, and the UI treats the chain as a first-class object: a stack navigator on each PR, a base-branch picker that knows about your other open branches, and a rebase button that walks the dependency graph when the bottom of the stack lands on `main`. Merge queue is wired in — merging the base PR retargets the child, kicks required checks, and moves the stack forward without a human hand-crank.

This is the workflow that Phabricator shipped in 2011, that Meta rebuilt as Sapling, that Google has run internally forever, and that Graphite turned into a $50M-funded startup because GitHub wouldn't ship it. The mechanics are unsurprising to anyone who's used any of those tools. What's new is that it's in the box — no CLI wrapper, no browser extension, no app to install into your org, no separate review surface that half your reviewers refuse to log into.

The preview is opt-in per repo for now, gated behind a repo setting. GitHub's changelog notes support for GitHub Actions, required status checks, CODEOWNERS, branch protection rules, and the merge queue — meaning the enterprise plumbing that killed most third-party stacked-PR adoption is already handled. The REST and GraphQL APIs expose the stack relationship, so bots and CI can reason about the chain instead of treating each PR as an island.

Why it matters

Stacked PRs solve a specific pain: the review unit and the change unit are not the same thing. A well-factored change is often 400 lines split across five commits, each of which should be reviewed independently but must land together. GitHub's model has historically forced you to pick one: mash it into a 2,000-line mega-PR that no one reads carefully, or ship five sequential PRs where PR #2 can't be reviewed until PR #1 merges — killing parallelism and dragging the whole change out for a week.

The teams that have already solved this problem — Meta, Google, and roughly every infra team at a company with >500 engineers — did it by leaving GitHub's PR model behind, not by working within it. Meta built Sapling and ghstack. Google runs Critique on a monorepo that doesn't use branches the way GitHub does. Graphite and Aviator built companies on the premise that GitHub's PR model was a permanent tax. That premise just got weaker.

The interesting question is what happens to the third-party ecosystem. Graphite raised a $52M Series B in 2024 on the pitch that stacked diffs plus AI review were the next-generation code review stack. The stacking mechanic is now a commodity; the differentiation collapses to AI review, analytics, and the CLI ergonomics of `gt` — which is real value, but it's a much smaller moat. Expect Graphite, Aviator, and the ghstack/Sapling crowd to pivot hard toward the AI-review layer over the next six months, because the plumbing they charged for is now free.

There's also the question of whether developers will actually use it. Stacked diffs have a learning curve that plateaus higher than the standard flow but starts lower — the first time you rebase a stack and hit a conflict three PRs deep, you understand why Phabricator shipped `arc land` instead of a UI button. GitHub's rebase-down-the-stack button will work fine for clean cases; it's the messy ones that will decide whether stacks become a mainstream pattern or stay a power-user feature. The merge queue integration helps a lot here — it's the mechanism that turns "rebase and hope" into "queue and forget."

Community reaction on the HN thread (261 points at time of writing) skews positive but weary: the top comment is essentially "finally," the second is a Graphite user asking whether they should switch, and the third points out that GitLab has had this since 2022 under a different name. The weariness is earned. GitHub shipped merge queues in 2023 after years of the community begging; stacked PRs are the same story on a longer timeline.

What this means for your stack

If you're on Graphite or a similar tool, don't rip it out this week. The native feature is in public preview, which at GitHub means "expect edge cases for six months." But do run a bake-off: pick a repo, enable the feature, have a few reviewers try it on a real refactor, and compare against your current flow. The specific things to test are (1) how the stack UI handles a force-push to the middle branch, (2) whether CODEOWNERS approvals cascade the way you'd expect, and (3) how the merge queue behaves when a mid-stack PR fails required checks.

If you're on vanilla GitHub and have been avoiding large refactors because the PR-splitting math didn't work, this changes the calculus. The right unit of review is now decoupled from the right unit of deployment — you can send four 200-line PRs that land as one logical change without begging reviewers to context-switch four times. The practical implication: refactors that used to sit in someone's fork for a month because splitting them was too painful now have a viable path to review.

For platform and DX teams, this is a lever. The old advice was "keep PRs small" and the response was "my change isn't small." The new advice is "stack it," and the response is a UI that actually supports it. Update your contributing guide, add a section on when to stack vs. squash, and consider making stacks the default for anything over ~500 lines. The teams that get good at this will ship faster than the teams that keep writing 2,000-line PRs.

Looking ahead

The interesting second-order effect isn't the workflow — it's what it does to code review culture. When a stack is cheap, the incentive shifts toward decomposing changes for readability rather than for merge-ability, which is the whole point Phabricator was making fifteen years ago. Expect a wave of "how we stack" blog posts from the usual suspects in Q4, expect Graphite to rebrand around AI review by year-end, and expect the next GitHub Universe to include a keynote line about how stacked PRs cut cycle time by some suspiciously round percentage. The workflow is finally native. Now the argument moves from "can we do this?" to "should we?" — which is a much better argument to be having.