If you've ever opened a PR with 47 changed files and a diff so long GitHub just gives up and shows you "Load Diff" seventeen times, this one's for you.
GitHub quietly shipped what might be the biggest pull request update in years, and it's aimed squarely at that problem.
Let's talk about stacked pull requests.
The problem, in one sentence Big PRs are where good reviews go to die.
Nobody reads a 2000 line diff carefully.
Some folks reach for AI code review tools like LiveReview to take the edge off, and honestly that helps, but even the best reviewer (human or model) does a better job on a tight, focused diff than on a 2000 line wall.
Smaller inputs, better reviews.
That's true no matter who's doing the reviewing.
Stacked PRs are GitHub's answer: break one massive change into a chain of small, dependent PRs, where each one only reviews the diff it actually introduces, not everything below it.
What a stack actually is The rule is simple.
You need two or more PRs in the same repo where: The bottom PR targets your trunk branch (usually ) Every PR after that targets the PR below it, not That's it.
That's the whole trick.
Foundational stuff (schemas, shared types) goes at the bottom.
Stuff that depends on it (API routes, UI) goes higher up the chain.
And here's the part that surprised me: if you just do this manually with plain git, by opening PR #11 against the branch for PR #10 instead of against , GitHub now recognizes that as a stack automatically.
No special tool required.
It just notices the base branches form a chain and lights up a banner.
Stacking isn't a git concept at all, it's purely a GitHub UI concept layered on top of branches you were already making.
Let's actually build one Enough theory.
I built a real stack in one of my own repos (peektea, a terminal file browser I maintain), using a harmless scratch file so nothing real got touched.
Here's the actual terminal session, copy pasted, warts and all.
First I tried to be fancy and use the CLI extension: Yeah.
Turns out needs a CLI extension or a newer version than the one sitting in my , and mine's from a Ubuntu apt repo that hasn't heard about this feature yet.
Software, everyone.
So I did it the "old school" way the docs mention, plain git branches, chained base to base, no extension needed.
Which, from git's point of view, gives you exactly what git always gives you: three branches sitting on top of each other like tired commuters on a train.
Nothing special yet.
This is just branches.
The magic happens once you push them and open the PRs with the right bases: Notice the on PR #11 is , not .
That one flag is the entire secret sauce.
And GitHub actually notices This is the bit that got me.
I expected to have to manually flip some setting somewhere.
Instead, the second I opened the top PR of the chain, GitHub just showed a banner: "This pull request can be stacked with other pull requests," with a "Preview stack" button sitting right there.
Clicking it pops up a little preview that walks the whole chain, top PR down to , correctly ordered, correctly linked, with zero config from me beyond opening PRs against the right base branches.
Hit "Create stack" and every PR in the list picks up a tiny progress badge, , , , right there in the pull request list, so you can see at a glance how deep any given PR sits in its stack without opening a single one.
According to GitHub's own docs on stacked pull requests, once you're happy with the whole chain there's a "merge stack" action that walks down and merges every PR in order in one go, no manual rebasing between each merge.
I didn't actually pull that trigger on my demo repo (closing four browser tabs is enough chaos for one blog post), but the docs and the UI both point at it being one button for what used to be N sequential merges plus N rebases.
Here's roughly what that flow looks like end to end, CLI or manual, doesn't matter which: Wait, didn't I already have this?
Kind of, and this is worth being honest about.
You could al