4 ms·

I'm not sure I understand how post-commit reviews handle the case when two people are both working on the same repository. For me, the reason to invest in testi

I'm not sure I understand how post-commit reviews handle the case when two people are both working on the same repository. For me, the reason to invest in testing and reviewing before merging to main is that once any person has merged, the rest of the team is subject to any issues in their code. Nor do I understand the argument that delaying reviews lets a developer iterate faster. If you are going to continue iterating on your work without waiting for feedback, why does it matter whether the work is merged in already or still on your side branch?

Izkata 6y ago
> once any person has merged, the rest of the team is subject to any issues in their code. Put another way, problems are more likely to be found before release. Actual example: Plenty of times things have passed code review on my previous teams, and only after merging to trunk and being forced to use the changes have the other devs encountered problems that needed to be dealt with. It does slow down the other dev, but unless it was something really obvious the two of them would typically pair on it until everything was good.