Then they start blaming the process instead of the developers who fucked up the code. If you broke the build, you fix the build is all the process a company needs.
This is a little over-simplistic, IMO. There's more to correctness and good code than "it didn't break the build." I've been there and got the T-shirt from an organization with that mindset and their code, five or more years after it's written, was terrifying in a lot of ways, because hey--none of it broke the build. I get that you probably have had run-ins with bad process, but that doesn't make all process bad.
I'm a big fan of Gerrit, personally; it encourages multiple sets of eyes on the code and I really like the "gatekeeper" approach to master. If I can't use Gerrit (and there are good reasons for not using it, often related just to development team size--Gerrit doesn't seem worthwhile for under, say, 20 devs), my personal preference is a riff off of git-flow; developers only push to develop-staging and CI constantly pulls changes from develop, builds, runs tests, and pushes to develop. Nobody other than the CI user (which anyone can log in as, but unless something's broken, you never would) can push to develop. This process (scary word!) allows us to say with authority "the build will never be broken when you pull from develop," and to me that has a lot of value--more and more as you add developers.
This is a little over-simplistic, IMO. There's more to correctness and good code than "it didn't break the build." I've been there and got the T-shirt from an organization with that mindset and their code, five or more years after it's written, was terrifying in a lot of ways, because hey--none of it broke the build. I get that you probably have had run-ins with bad process, but that doesn't make all process bad.
I'm a big fan of Gerrit, personally; it encourages multiple sets of eyes on the code and I really like the "gatekeeper" approach to master. If I can't use Gerrit (and there are good reasons for not using it, often related just to development team size--Gerrit doesn't seem worthwhile for under, say, 20 devs), my personal preference is a riff off of git-flow; developers only push to develop-staging and CI constantly pulls changes from develop, builds, runs tests, and pushes to develop. Nobody other than the CI user (which anyone can log in as, but unless something's broken, you never would) can push to develop. This process (scary word!) allows us to say with authority "the build will never be broken when you pull from develop," and to me that has a lot of value--more and more as you add developers.