Stacking PRs Without Losing Your Mind (or Your Velocity)

Generally speaking, I’m a big fan of trunk-based development. There’s plenty online about what it is, but in short, it’s a workflow where you’re constantly merging into a trunk or main branch, and you branch off from there whenever you’re making new changes.

There’s a lot of goodness baked into trunk-based development: it naturally encourages continuous integration, sets the stage for continuous deployment, promotes the use of feature flags, forces testing discipline, enables faster and better code reviews, and can be a solid forcing function for thinking in smaller, incremental changes.

But what happens when you are working on a large and complicated feature, and you are waiting on code reviews for previous PRs because your next ones depend on them?

That’s where stacking workflow comes in.

Now, folks often do stack PRs by branching off an existing branch instead of main. The problems start when you need to stack more than two or three PRs, and upstream feedback changes need to cascade down through the rest of the stack.

That’s where proper stacking workflow tools earn their keep. They actually work quite well with trunk-based development because you’re still merging into main, sequentially, not into a long-lived feature branch.

That said, I’ll go to great lengths before resorting to stacking. That’s a post for another day; trunk-based development strategies for big features.

There are a bunch of CLI tools that help you manage stacked PRs, the one that I’ve used with success is git-town (which has many other useful features as well).

Even if you do use stacking, “tall” stacks suck. They’re an anti-pattern. Keep your stacks as small as possible. Push for reviews on your earlier PRs and merge them quickly to keep the chain tight.

Stacking helps you increase your velocity and keep up your momentum, but the single responsibility principle still applies to every PR. The moment you break that, you’re signing yourself and your team up for a world of pain.

Yes, there will be times you bend that rule. But think very, very hard before you do.

There’s more I’ll say on this topic another time, but for now, I’ll leave you with this: there’s a natural intersection between trunk-based development and the stacking workflow, and it’s worth understanding both if you want to move fast without breaking things.

Comments

2 responses to “Stacking PRs Without Losing Your Mind (or Your Velocity)”

  1. Sanjucta Avatar
    Sanjucta

    git-town seems cool. It looks like something you could start using even if the rest of your team has not adopted it yet.

    1. Aurooba Avatar

      Yes! I think it works even better when the whole team has adopted, but it certainly isn’t a requirement. Having this workflow in your project repo helps though: https://github.com/git-town/action

Leave a Reply

Your email address will not be published. Required fields are marked *