Stop Waiting. Start Stacking Your Pull Requests.

I see this pattern all the time. A developer opens a pull request, then sits idle. They’re waiting for a review. Maybe they check Slack. Maybe they context-switch to something unrelated. Maybe they just… wait.

The reason? They’re afraid. Afraid that if they keep building on top of unreviewed work, they’ll end up in merge conflict hell. Or they believe the first PR must be approved before any follow-up work makes sense.

Both fears are overblown. And the cost of waiting is real.

Stack your PRs

The fix is simple: create a follow-up branch based on your current feature branch, not main. Keep working. When it’s time to open a pull request for the follow-up, point it at your parent branch instead of main.

That’s it. That’s the trick.

Both GitHub and Bitbucket handle this well. When your first PR gets merged, they’ll automatically retarget the follow-up PR to main. The chain resolves itself. You don’t have to babysit it.

This means you can have two or three PRs in flight, each building on the last, while reviewers work through them at their own pace. Nobody is blocked.

If conflicts do come up (say the first PR gets changes during review) you can merge the parent branch back into your follow-up or rebase onto it. Just be careful with rebasing stacked branches. It’s easy to introduce duplicate commits or ghost conflicts if you’re not paying attention. When in doubt, merge. When you’re confident in your git skills, rebase.

Keep your merge commits clean

Here’s a related habit I see go wrong constantly. Developers merge main (or develop) into their feature branch to stay in sync, and in the same breath, they sneak in new changes alongside the merge commit.

Don’t do this.

A merge commit that pulls upstream changes should contain only upstream changes. Nothing else. The moment you mix your own work into a sync merge, the commit history becomes unreadable. Reviewers can’t tell what came from upstream and what’s new. Blame gets polluted. Debugging gets harder.

If you need to sync, sync. Commit it. Then make your changes in a separate commit.

Better yet, rebase your feature branch onto the latest main and force-push. It keeps the history linear. Yes, force-pushing rewrites history. That’s fine on a feature branch that only you’re working on.

I wrote more about why your commit history matters in Your Commit History Is Part of Your Job.

Let AI handle the tedious parts

One more thing. If you’re stacking PRs and rebasing regularly, you will run into conflicts eventually. That used to be a real deterrent. It isn’t anymore.

Tools like Claude Code and Codex are surprisingly good at resolving merge conflicts if you give them clear instructions. Tell them which version to prefer, describe the intent of your changes, and let them sort through the mechanical noise. Conflict resolution is tedious and pattern-heavy. Let a machine do it. Save your brain for the actual problem you’re solving.

Waiting for PR reviews is one of the most common productivity killers on engineering teams. Stacking PRs doesn’t eliminate the need for reviews. It just decouples your momentum from someone else’s availability. Stop waiting.