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.
Leave a Reply