GitHub finally shipped stacked PRs — Graphite has a problem

What happened

GitHub moved stacked pull requests into public preview on July 30. In the new UI, a PR can declare a parent PR instead of a branch, and the base of the stack is rendered as a linked chain across every PR page in the stack. When you merge the bottom PR, GitHub auto-retargets each child PR to the new base and rewrites the diffs so reviewers only see the delta that belongs to that step — not the accumulated churn from earlier merges.

The mechanic that matters is that GitHub is doing the rebase-and-retarget server-side, on merge, without asking you to run `git rebase --update-refs` locally or push a rewritten history for every child branch. That was the single hardest part of maintaining a stack by hand, and it is the reason a cottage industry of CLI tools exists in the first place. The preview supports both squash-merge and merge-commit strategies, with the retarget happening as soon as the parent lands on the base branch.

Availability is behind a repo-level opt-in for now — org admins flip it on per repository, and the UI surface appears in the PR creation flow, the PR conversation view, and the mergeability box. GitHub says CLI (`gh`) support is coming; today the stack is created and reordered through the web UI or via a REST field on the pull-request create call.

Why it matters

Stacked PRs are the answer to a specific reviewer problem: a 1,400-line diff nobody reads carefully vs. seven 200-line diffs that each land a coherent step. Every serious engineering org that has tried to enforce small PRs has run into the same wall — Git's branch model punishes you for chaining work. Rebase one branch and every branch built on top of it needs to be rebased too, in order, without dropping commits, and the PR bases on the server have to be updated to match. Miss a step and reviewers see a diff full of code they already approved on the previous PR.

Meta solved this internally with Phabricator and later ghstack; Google solved it with a monorepo and Critique; Sapling exposed the workflow to the outside world; Graphite built a $50M+ business around wrapping the ergonomics on top of GitHub. The common thread is that the platform itself refused to model the dependency, so tooling grew up around it. That gap is what GitHub just closed.

The community reaction on the HN thread (591 points at time of writing) is roughly split between "finally" and "about ten years late." A recurring complaint: the preview still requires you to author the stack as a set of pre-existing branches — there is no `git stack push` equivalent that takes a series of commits and fans them out into linked PRs the way `ghstack` or `spr` do. That is the piece Graphite users will miss on day one, and it's the obvious next feature.

The more interesting question is what this does to the third-party stacking market. Graphite's core pitch has been "GitHub can't do this, so use our CLI and dashboard"; when GitHub can do this, the pitch collapses to "our UI is nicer," which is a much harder sell at $20/user/month. Sapling and ghstack are open-source and Meta-funded, so they'll survive on ideology and existing users. `spr` and the various homegrown wrappers were already hobby-scale. Graphite is the one with real revenue exposure, and their move will almost certainly be up-stack — into review automation, merge queues, and AI-assisted review — because the plumbing layer just got commoditized.

There's also a subtler platform story. GitHub has been shipping the boring-but-essential plumbing features (merge queues in 2023, required workflows, sub-issues, now stacked PRs) at a pace that suggests they finally believe the enterprise-DevOps land grab is worth defending against GitLab and internal platforms. For years the criticism was that GitHub coasted on network effects and let the workflow layer stagnate. That story is harder to tell in 2026.

What this means for your stack

If you're already on Graphite or a similar tool, don't rip it out this week — the preview has rough edges (no CLI, no `gh` integration, branch-authored only) and your team's muscle memory has a real cost. But do put a review on the calendar for Q4. The moment `gh pr create --stack` ships and the auto-retarget behavior stabilizes, the case for a paid third-party layer becomes hard to justify to a CFO who is already asking why the GitHub bill went up.

If you're a team that has been avoiding stacked PRs because the tooling was too fiddly, this is the moment to try again. The reviewer-side experience is where the value actually lives — a well-stacked change makes review qualitatively better, not just faster. Start with a two-PR stack on a low-stakes refactor and see how your team reacts to the new UI before you evangelize.

For platform teams: audit your merge-queue and branch-protection rules before flipping this on org-wide. Auto-retarget interacts with required-status-checks in ways that aren't fully documented yet — specifically, whether a child PR needs to re-run its full CI matrix after the base rewrites underneath it. On big monorepos with 30-minute CI, that difference is the difference between "stacked PRs are great" and "stacked PRs quadrupled our Actions bill."

Looking ahead

Expect the CLI to land within a quarter, expect Graphite to pivot toward AI review and merge orchestration, and expect a wave of internal RFCs at large orgs about whether to standardize on native stacks. The interesting fight over the next 18 months isn't whether stacked PRs win — that's decided — it's whether the review layer stays inside GitHub or gets eaten by an AI-native competitor while GitHub is busy shipping the plumbing everyone should have had in 2018.