Thanks, great addition!

Hi Mike, thanks for letting me know. Unfortunately, I did not find a new version of this blog post anymore.

Do you know of an alternative way to access Grayson Koonce’s post? It seems to be unavailable now. 🙁

The developer opens stacked PRs, similar to how you described. Code gets reviewed in the order the PRs were opened, and gets merged in the order the PRs were opened.

In fact, there should be an emphasis to get PRs merged into the trunk/main/master branch asap.
The goal here is not only to get the code reviewed in smaller chunks, but also let it become part of the code base in smaller chunks.

This approach is very scalable, and is easy to adopt because it’s very rare to have more than 2 stacked PRs (since PRs are merged asap).

[1]: https://trunkbaseddevelopment.com/

Thank you, Marco!

Hi Nicolas,

you review the changes from bottom to top (as you suggested), but you merge them from top to bottom. The reason for this is merely a technical one (how git and branches work). But, you are right, if git or the tooling around would support it more easily, it would make sense to merge the PR right after you reviewed it and thus bottom to top. But this will create more merge conflicts and hassle with the branches for you. So, that’s the reason why I recommend merging only after you reviewed the whole stack. Then, you integrate and merge the stacked together.

Yes, you are right. It’s not trivial. It’s a workaround that helps us improve code comprehension for the reviewer. Unfortunately, the current tools such as GitHub, Gitlab, and Bitbucket do not support this use case natively. I hope over time, it will be easier for the developer by using tooling to do this.

About merging stacks of PRs, I’m surprised you advise to merge top to bottom, while doing the reverse seems more logical to me.
For example, if doing so, when starting by merging fb-ui -> fb-businesslogic, someone willing to review the changes brought by fb-businesslogic, would have then to take into account the aggregated diff of the two branches, while the fb-ui part has already been reviewed and considered ready for being merged. And even if aware of this, the reviewer would see a diff, polluted by already reviewed changes.
What’s more, between the time fb-ui has been merged into fb-businesslogic, the develop branch can have changed in a way that makes fb-ui not mergeable into it anymore.

That’s why in this kind of situation, we tend to encourage doing the contrary, that is reviewing then merging fb-database first. the fb-businesslogic PR will get retargeted automatically by tools like bitbucket (but it can be done manually too).
This approach allows to really split the reviewing / merging process into smaller, more independent chunks IMHO. But of course, it relies on each individual branch being robust enough to not break develop until the 2 other PRs can be merged.