Back to News & Insights
Web Development August 10, 2026 · 7 min read

Ayo GitHub Quietly Killed the Unreviewable Mega-PR

If you've ever opened a PR with 47 changed files and a diff so long GitHub just gives up and shows...

Ayo GitHub Quietly Killed the Unreviewable Mega-PR

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.

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.

The rule is simple. You need two or more PRs in the same repo where: The bottom PR targets your trunk branch (usually main) Every PR after that targets the PR below it, not main

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 main, GitHub now recognizes that as a stack automatically.

Stacking isn't a git concept at all, it's purely a GitHub UI concept layered on top of branches you were already making.

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.

Yeah. Turns out gh stack needs a CLI extension or a newer gh version than the one sitting in my $PATH, and mine's from a Ubuntu apt repo that hasn't heard about this feature yet.

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.

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 main, 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, 1/3, 2/3, 3/3, 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.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation