GitHub Finally Gets Stacked PRs — Here's What Changes

What Happened

GitHub has published gh-stack, an official CLI extension hosted at github.github.com/gh-stack, that brings first-party stacked pull request support to the platform. The tool extends the `gh` CLI — GitHub's existing command-line interface — with commands to create, manage, and land chains of dependent pull requests.

For the first time, GitHub users can break a large changeset into a sequence of small, dependent PRs and manage the entire chain as a unit — without third-party tooling. The release drew 636 points on Hacker News, signaling significant pent-up demand from a developer community that has been working around this gap for years.

Stacked PRs (also called dependent diffs, patch chains, or stacked diffs) are a workflow where a large change is decomposed into an ordered series of small pull requests, each building on the last. PR #2 targets PR #1's branch instead of `main`. When PR #1 merges, PR #2 automatically retargets to `main`. The result: reviewers see small, focused diffs instead of a 2,000-line monster.

Why It Matters

### The Problem gh-stack Solves

GitHub's PR model has always been flat. You branch from `main`, make changes, open a PR back to `main`. This works fine for small features, but it falls apart for anything substantial. A 1,500-line refactor-then-feature PR is painful to review, slow to land, and prone to merge conflicts that compound over time.

The alternative — manually managing a chain of branches where `feature-part-2` targets `feature-part-1` — works in theory but is an operational nightmare. When you rebase `part-1` after review feedback, you have to manually rebase `part-2`, `part-3`, and every downstream branch. One wrong `git rebase` and you're spending an afternoon in reflog archaeology.

gh-stack automates this entire cascade: when you amend a PR in the middle of the stack, it rebases all downstream PRs automatically. This is the core value proposition — not creating the stack, but maintaining it as it evolves through code review.

### A Decade-Old Gap

This workflow is not new. Facebook's Phabricator (now archived) built its entire review system around stacked diffs. Google's internal tools and Gerrit have supported dependent change chains since their inception. The Linux kernel's email-based patch series workflow is essentially stacked diffs over SMTP.

GitHub's flat PR model was a deliberate simplification that made the platform accessible — and then became a constraint as teams scaled. The gap between 'GitHub is where code lives' and 'GitHub's review model can't handle how we actually work' spawned an entire category of third-party tooling.

Graphite (YC W21) raised venture capital specifically to build stacked PRs on top of GitHub. spr (Shopify-originated) took a lighter approach with a single-binary CLI. git-branchless reimagined Git's UX wholesale, with stacking as one feature among many. Aviator (now Aviator MergeQueue) bundled stacking with merge queue management. Each tool had tradeoffs: Graphite required a hosted service and web dashboard; spr was minimal but opinionated about one-commit-per-PR; git-branchless was powerful but had a steep learning curve.

The fact that multiple well-funded companies and popular open-source projects exist solely to add this feature to GitHub tells you everything about the demand.

### What gh-stack Gets Right

By shipping as a `gh` CLI extension rather than a standalone tool, GitHub made a shrewd architectural choice. There's no separate auth flow, no additional service to trust with repo access, no new mental model for developers already using `gh pr create` and `gh pr merge`. It slots into existing workflows rather than replacing them.

The extension manages the dependency graph between PRs, handles the cascade rebase when any PR in the stack is updated, and provides commands to visualize the current state of your stack. PR descriptions are annotated with navigation links showing where each PR sits in the chain — a small touch that matters enormously for reviewers trying to understand context.

For reviewers, each PR in the stack shows only its own diff, not the cumulative changes from parent PRs — solving the single biggest pain point of reviewing dependent PRs on GitHub.

What This Means for Your Stack

### If You're Already Using a Stacking Tool

Don't rush to migrate. Graphite, spr, and git-branchless are mature tools with features gh-stack may not yet match — Graphite's web UI for stack visualization, spr's commit-centric workflow, git-branchless's undo system. Evaluate gh-stack when your current tool's renewal comes up or when onboarding a new team. The switching cost is low since all these tools operate on the same underlying Git primitives.

That said, the gravitational pull of first-party tooling is real. New team members are more likely to adopt `gh stack` than install a third-party CLI. Documentation and Stack Overflow answers will increasingly assume the official tool. This is the "good enough and built in" dynamic that has historically compressed entire tool categories.

### If You've Been Doing Stacking Manually

Stop. Install `gh-stack` today. The time you spend manually rebasing dependent branches is pure waste that a tool can eliminate. Even if gh-stack is missing features you want, the baseline of "auto-cascade rebase" alone justifies adoption.

### If Your Team Does Big PRs

This is your forcing function to adopt a stacked workflow. The tooling barrier — the primary reason teams tolerated 1,000+ line PRs — is now gone. Start with a simple two-PR stack: one for the infrastructure/refactor, one for the feature that uses it. The review quality improvement is immediate and measurable.

### Impact on the Ecosystem

Graphite is the most directly affected. Their pitch — "stacked PRs for GitHub" — now competes with GitHub's own offering. The company has been diversifying into merge queues, CI optimization, and developer analytics, which looks prescient in retrospect. Expect Graphite to accelerate that pivot and emphasize their web UI, team analytics, and enterprise features as differentiators.

For spr and git-branchless, which are open-source and maintained by smaller teams, the impact depends on their feature delta. If gh-stack covers 80% of use cases, the remaining 20% may not sustain active development communities.

Looking Ahead

GitHub shipping stacked PRs is part of a broader pattern: the platform is methodically closing the gaps that pushed advanced users to external tooling. Merge queues, required status checks, code owners, and now stacked PRs — each feature that ships natively reduces the surface area for third-party developer tools. For practitioners, that's unambiguously good: fewer tools to configure, fewer auth tokens to manage, fewer vendors to evaluate. For the developer tools ecosystem, it's a reminder that building on top of a platform means building on borrowed time. The best tools in this space will be the ones that moved upstack before the platform caught up.