---
title: "Stop Waiting. Start Stacking Your Pull Requests."
description: "Waiting for PR reviews is one of the most common productivity killers on engineering teams. Instead of sitting idle, stack your pull requests by branching off your current feature branch and pointing follow-up PRs at the parent branch. Both GitHub and Bitbucket handle retargeting automatically when the first PR merges."
date: 2026-02-25
tags: ["git", "pull-requests", "productivity", "best-practices", "software-engineering", "team-collaboration", "code-review"]
author: "jan-kraus"
url: https://www.liberateweb.com/blog/stop-waiting-start-stacking-your-pull-requests/
source: LiberateWeb
---

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](https://www.liberateweb.com/blog/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.