| > You can happily pull master with a test fail. No, you can sometimes pull master with a test fail and knowing which tests are ok to fail is a skill in itself. > That does presume you are OK with collective responsibility for the codebase That only works on small projects and on "simpler" projects. On my last project with 100+ developers it was likely that a bunch of the failures could only be fixed by 1-2 people. Asking a tools programmer to fix a failing networking test, or a gameplay/network programmer to fix a material bug is a stupid waste lf time. > If you insist one dev per branch and that dev merges, thats playing blame games That's a strawman. Nobody is talking about one dev branch per person except you. There are other branching models (git flow, task branches or even feature branches) with well defined criteria for merging back to main available that allow for multiple team members and stability in main. > We all know breakage is inconvenient so we all try not to do it on branches or trunk. This is a very naive view and is the equivalent of "just make sure it works before you submit", and doesn't scale into even tens of developers working on a project in my experience. |