GitHub Finally Made Stacked PRs Official: Goodbye Long-Branch Hell — But Don't Roll It Out to Everyone Yet

Your PR has been sitting there for three days. The feature was done ages ago — the branch is what's stuck. From the moment you cut it off main, it's been fighting every other branch in the repo. Main moves, you rebase. You finish resolving conflicts, main moves again. Then a reviewer finally opens the PR, sees a 300-file diff, and closes the tab.

That's not on you. That's the ceiling of "one feature, one branch."

GitHub just shipped gh-stack, an official tool that drags stacked pull requests out of third-party-plugin territory and makes them a first-class workflow. When a platform this big ships its own version of something, read it two ways: the need is real, and this is about to become the default.

What stacked PRs actually are

A normal PR is a tree. Every branch grows out of main, minding its own business. A stacked PR is a chain:

frontend      → PR #3 (base: api-endpoints) ← top
api-endpoints → PR #2 (base: auth-layer)
auth-layer    → PR #1 (base: main)          ← bottom
─────────────
main

Each branch sits on the one below it, not on main. When you submit, GitHub opens one PR per branch and wires each PR's base to the branch beneath it.

Here's the payoff. A reviewer opening any PR in the stack sees only that layer's changes. Not 300 files — three files, one clear topic.

Put it another way: a normal PR hands one person the entire project as a single giant diff. A stacked PR cuts that same change into small steps, each one reviewable and mergeable on its own.

Why GitHub shipping its own matters

Stacked PRs aren't new. Graphite and friends have done this for years, and plenty of big companies run internal scripts for it. Until now, though, it stayed a power-user play:

• Third-party tools want a subscription, and your data lives on someone else's servers
• Internal scripts need an owner, and nobody's on call when a rebase dies halfway through
• Everyone on the team carries a different mental model of branching, so strategies splinter

gh-stack kills all three. It's a gh CLI extension, one command:

gh extension install github/gh-stack

Stack metadata lives in a local .git/gh-stack directory — a JSON file you never commit. No third-party service, no new data silo. It binds to your GitHub repo and nothing else.

One detail I like: gh stack init turns on git rerere for you. Rerere remembers how you resolved a conflict and reapplies that resolution the next time the same conflict shows up in a rebase. Somebody was thinking about real large codebases here, not a demo.

How to actually use it: ten minutes to try

Four commands cover the core flow:

# Start a stack: creates and checks out the first branch
gh stack init

# Add a new branch on top of the current stack
gh stack add api-endpoints

# Push all branches
gh stack push

# Create a PR for every layer, with bases wired correctly
gh stack submit

gh stack add also does the whole dance in one shot — stage, commit, and auto-generate a branch name:

# Stage everything, commit, auto-name the branch (e.g. 03-24-add_login)
gh stack add -Am "Add login endpoint"

Moving between layers is painless: gh stack checkout takes a branch name, a PR number, even a PR URL. gh stack view prints the whole stack.

The learning curve is gentler than you'd fear. You don't unlearn git; you get an orchestration layer on top of it. Anyone already maintaining dependency chains by hand will wonder why they spent so long doing it the hard way.

Cold water: when NOT to use it

Stacked PRs aren't a silver bullet, and I'd hold off on rolling them out team-wide.

Small changes don't need it. A PR that's a few dozen lines across two or three files gains nothing from stacking — it's pure overhead. Chains add mental load instead: which layer is this change in? Does merging the middle layer affect the top one? If this layer's rebase blows up, does the whole thing domino?

Solo projects don't need it. You're your own reviewer. Nobody's asking to see one layer at a time. Stacking solves a collaboration problem, not a personal productivity one.

Teams with heavy rebase churn should tread carefully. The longer the chain, the harder the ripple hits. One conflict in a middle layer can drag down the layers above and below it. Rerere absorbs some of that, but a human still resolves the conflict. If your branches constantly step on each other, go find out why you have conflicts — don't bury the question under a more complex structure.

The tool is young. GitHub flags it as early-stage itself. Watch a few release cycles and let the community kick the tires before you adopt it in production at scale. That's the normal cadence for official GitHub tooling.

My take

Working in a large codebase on long-lived features? Team PRs routinely past a hundred files? Give it ten minutes today. Run gh stack init, build a two-layer stack, walk through add and submit, and look at what the reviewer sees.

Small changes, solo maintenance, or no branching discipline to speak of? Skip it. Nailing down a basic branch strategy will do more for you than any new tool.

Stacked PRs solve exactly one problem: getting a big change reviewed properly. GitHub shipping its own version graduates the workflow from power-user trick to standard practice. Standard practice still isn't universal fit, though — this tool is for teams that can actually use it.

---

References

• GitHub official gh-stack repo: https://github.com/github/gh-stack
• 码农早餐 · 2026-08-02: GitHub releases official Stacked PR tool

✨ Drafted by DeepSeek, edited by Claude.