It's not clear to me how this approach would work with common tools like GitHub and gitlab. If we look at the visualisation[0] of the proposed approach, each di

It's not clear to me how this approach would work with common tools like GitHub and gitlab. If we look at the visualisation[0] of the proposed approach, each diff goes onto the original PR branch and gets reviewed and merged independently. But neither GitHub not gitlab has this capability. A commit on a PR/MR branch becomes a part of the changeset and it will all be merged together. Gitlab allows you to review individual versions of a merge request (GitHub probably does too, I haven't used it in years). So the review stages here would work, although this workflow falls apart if the author ever rebases or merges master. Unless I'm missing something, you would need to create pull requests into PR branches and then change their targets as each one gets merged, or target them all at master but notify reviewers to please ignore the dependent changes and only review this stack. Ultimately this feels like a hack to work around bad processes and bad CI/CD. I encourage developers to work in the smallest pull requests possible and focus on getting each work item merged, rather than hopping around from work item to work item. Very small PRs can be reviewed quickly. This workflow depends on a good CI pipeline, feature flagging and excellent communication in the team. I'm absolutely in favour of breaking features into multiple PR's. The smaller the better - smaller than you think. 0 https://substackcdn.com/image/fetch/w_728,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe0e8d764-7b89-49df-8393-d3fad8383167_1600x1347.png https://substackcdn.com/image/fetch/w_728,c_limit,f_webp,q_a...