3 ms·

I don't know what kind of products these strategies work well on. I've only had experience with larger, older systems where multiple devs are making changes to

I don't know what kind of products these strategies work well on. I've only had experience with larger, older systems where multiple devs are making changes to fix specific issues that the other devs are not completely in the loop on. We might know dev A is working on this ticket, but we are busy with our own tickets and can't always have collaborative design reviews for every item. Maybe that isn't ideal, but it is reality for a lot of teams. The pre-commit code review is our opportunity to stay in the loop and a bulwark against technical debt and silly mistakes before they ever touch a core branch.

krab 6y ago
Post-commit review worked quite well when I worked on a product with quarterly release cycle. The master had to stay green (or blue, actually) and all commits should have been reviewed before release. Each feature had its own short lived branch. Architectural issues and larger refactorings were of course discussed in advance. Because the code wasn't released that often, it didn't matter that much if the review was done in master or in the feature branch and this way minimized conflicts. I wouldn't recommend it for a system with frequent deployments and more than a handful of developers.