Okay, wait, is it a common practice to push changes to master that you KNOW break some other features? I always assumed that that's what branches are for and master should be the "to the best of our knowledge it should be production ready"? But apparently in this company you need to hunt for the right revision, interrogating people why suddenly nothing works on your end and half the time it's "oh, this guy has been working on something and it broke half of the stuff others have been working on and isn't covered in tests yet. Use revision 21xkcd7a"

Them: Sorry 21xkcd7a doesn't seem to exist. Please send me the right one.

some people call our master branch a garbage dump. it's because some devs "blindly" merge their stuff from other release branches into the master branch and don't test it. i think they do it rather out of time pressure than out of laziness / carelessness...

Wrong question as extreme sloppyness is common practice.

But should it be done this way: Hell no!

You should convince them to do the proper branch, rebase, test, merge workflow.

Protect the main/master branch.

Force usage of Git flow
https://nvie.com/posts/...

Master should be redeploy-able at a moments notice and constant mirror of production (less environment specifics), if it's not stable it's not the master branch.

In my team, nobody can push to master. The only way to push changes to master is via a PR and the PR requires three reviews at least. It’s quite a large team though.

@latisfeire

For this project there are around 100 developers. There is a screen showing test results for branches (which are done AFTER merging) and master is more often red than not.

So far every project I worked on had pretty well defined master rules. The master should always be buildable, runnable and deployable at all times. We had projects where master was unlocked for everyone to push into, but even then all the devs on the project were conscious about this and no one just pushed stuff into the master all willy nilly. Everything went through either a PR or at the very least we called someone over to our desk if he was walking around and asked if it looks good and if we can merge it into master directly. but these were tiny tiny changes, like new keys if old expired or some boolean logic fixes that was glaringly obviously fixable and wouldn't break anything. But even that is not a good practice. your master should be locked, only fully trusted individuals should have access to it, and it should always be only mergable by PRs with at least 1 other approval