I used to open PRs with 800 lines changed and wonder why my team took two days to review them.
I am one of the founding engineers in a 15-person startup. We work quickly. There is no review team available or asynchronous reviews that can take days due to different time zones.
If a PR takes two days, the whole pipeline for that feature stalls.
The Guilt-Driven Scroll
It wasn't waiting the two days that bothered me most. It was the fact that when the review finally did come in, 200 lines were read thoroughly, and the rest got the "looks good to me". Every time.
This is not reviewing, it is trying to get out of guilt by scrolling.
What Stacked PRs Actually Look Like
I started using stacked PRs about a year ago. I wouldn't go back. The concept is simple: instead of one giant PR per feature, you break it up into a chain of small, dependent PRs that build on each other.
Sounds nice in theory, but how does it actually work? Let's say I am building a new data pipeline and I have to update the schema, API, frontend, and tests. Instead of one gigantic PR which includes all that:
→ PR 1 is the schema migration
→ PR 2 is the API endpoint, branched off PR 1
→ PR 3 is the frontend integration, branched off PR 2
→ PR 4 is the test coverage, branched off PR 3
I open four PRs. Each is under 200 lines. Each is reviewable in less than 10 minutes. Each small PR simply does whatever the next logical step in the change is and doesn't block the next step.
While I wait for PR 1 to get merged, PR 2 and 3 are already opened, so I don't have to wait. I just keep on building.
The Shift
The change this brought in my workflow was revolutionizing. My PRs used to wait 24-48h. They get reviewed the same day now. Sometime within the hour.
It's not because they are faster to write: but because they are not as intimidating. Your average 150ish-sized PR doesn't lead a reviewer to think "I don't have time to go through 800 lines". They think "I can glance at this before lunchtime". And that's in their lunchtime.
800-line reviews are rushed. Rushed reviews are buggy.
SmartBear's research on code review found a significant drop in defect density when reviewers go faster than 500 lines of code per hour. The point isn't speed. It's that large reviews force people to rush, and rushing means missing bugs.
Why Big Tech Already Does This
There is a reason why Meta and Google have used stacked diffs internally for years. Facebook built Phabricator around this workflow. Google's internal tools enforce small, incremental changes by default.
These companies aren't tiny startups optimizing a process, these are companies that send millions of lines of code and diffs per year to production and need their review process to be as secure and painless as possible.
The Tooling Is Painless
The tooling is painless. I use Graphite, which really only offers the feature of handling dependencies and rebases for you. 99% of the time, it just works. The training takes 5 minutes if you know how to git.
It's also a mental switch. When you are used to stacks, you naturally create better-defined features. You go from "how do I push this entire thing in prod" to "What's the smallest, useful change I can make?".
That decomposition makes you a better engineer. Not because the tool is magical, but because it forces you to think about boundaries, interfaces, and incremental value.
The One Tradeoff
The only real tradeoff is that you have to think about your PRs before even writing any code. You can't just go ham for 3 days and separate the 1k impressive lines into 6 equally big PRs afterwards.
You have to think what the chain will look like, and while for me, that's 10 minutes of planning, I reckon planning is not for everyone. It saves up so much wait time though.
If you review a lot of code, you already know the pain of a 1000-line PR landing on your desk. And if you write a lot of code, you know the frustration of being blocked on review while your feature rots on a branch.
Stacked PRs fix both sides. Smaller changes for reviewers. Unblocked workflows for authors. It's one of those workflow changes where you wonder why you didn't do it sooner.
What's your team's PR workflow like? Still shipping big PRs, or have you made the switch? 👇
Top comments (0)