Stacked PRs – Pros and Cons?
I love stacked PRs (though I prefer to call them &quot;cascaded MRs&quot; or similar because I find it easier to explain how they work to people that way).<p>You&#x27;ve covered the major pros at a high level, but I think the details matter. For example &quot;smaller PR&quot; is a rather high-level pro which is true. But it&#x27;s not just that PRs are smaller, but that they can be ordered to build functionality as a story and justify each change. This is much like how the Linux Kernel wants patch series and not just a single big patch. I find this helps make reviewing easier and faster. It can also help clarify some people&#x27;s thinking.<p>Similarly, &quot;keep working&quot; is a high level truth, but it has important organizational consequences. For example, if there is no rush to merge things it means the entire team doesn&#x27;t need to be interrupted several times a day to merge something. It also mean it&#x27;s OK to open a deep discussion on something in the MR. I find both these make the team as a whole more productive because they can take the time to think. For example, I push my team to only do reviews once a day so they don&#x27;t need to context switch and it gives discussions time for well thought out replies instead of rushed single-sentence responses.<p>There are some cons which are by no means insurmountable, but aren&#x27;t free to solve.<p>The biggest one is teaching everybody on the team how to use cascaded MRs in a technical sense. The details depend on how you implement them, but I prefer cascaded branches with full merge commits. Tooling can help, but if they don&#x27;t understand the underlying mechanics there will undoubtedly be problems where people can&#x27;t get the review to look like what they want.<p>Secondary to this is teaching what a good patch series looks like and how to use the VCS to create it. Each PR really needs to pass CI on its own, which requires ordering code changes in a particular way which is opposite the order they were mostly likely implemented. For example, while working on something you&#x27;ll probably notice a bug or refactor which needs to be done, but you only notice it  mid-way through the work. So you want to move the refactor&#x2F;fix to before the main work in the series. There are different ways to do this with different trade-offs and developers need to understand how and when to use them.<p>Finally, the biggest problem I&#x27;ve seen with stacked PRs is difficulty bringing in changes from master or whatever the parent is. With a single PR this is an easy merge&#x2F;rebase. With a long series of these it&#x27;s a repetitive series of merges (my preference) or rebases. Doing this manually is annoying and writing automation for it requires formalizing branch (or whatever) parent-child relationships. This isn&#x27;t terribly difficult, but ideally the command line and IDE and repository viewer and code review software all agree on it, which is a bunch of tedious work.