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.

You can always "fix" the broken test by reverting the offending commit. But again, if someone has already committed on it, your history will be a mess. Actually fixing something takes developer B longer than it will take the dev who knows the context. So switching that responsibility - unless it's a typo - would be a massive waste of time. A nice "collective responsibility" perhaps, but a huge waste of time.

> That does presume you are OK with collective responsibility for the codebase, but I have never worked without that. If you live in that world, I feel bad for you son ;)

I do like having collective responsibility. But one of the most important responsibilities is having a clean history, a buildable branch to start from etc. "Fixing other people's typos" is a nice team excercise but it's pretty far down on my list of collective responsibilities.

> If the same issue is on a branch its still there, its hidden and lives longer.

Test failures when we did commit-to-master lived for days or weeks. Working with PR's doesn't slow me down at all. It's not like feature branches have to live for days. They can live 20 minutes. Of course, if you have a 1.5h CI and then wait for a code review, then it's going to be a few hours, but I wouldn't want to go back to churning on master with 30 others. I did that for 15 years before. With all kinds of teams.

> If you insist one dev per branch and that dev merges, thats playing blame games.

I don't care who merges. And whether the dev merges their own code or whether code review is required is a tangential question. The more important point is that the branch lets build+test be done while the dev does something else, and that the target branch is green in the meeantime. Again, if you can build+test in minutes, then perhaps doing master dev is fine because you can all just agree that "Team, let's try to compile and run all tests before committing to master ok thanks". But if you have a lenghty CI then what? Do you hope every dev runs the 3 hour test suite before committing? That also sounds like a massive waste of time where the developer could be working on the next thing already.