Me when the intern commits some shit to master

You should be shooting whoever set up the remote to allow commits to master

@nibor was thinking the same although some setups deploy by pushing to the server or pulling from server. Harder to set up branch protection in you don't use a fancy git server.

@hjk101 Then shoot the one who chose the git server.

@sbiewald but there is none...
At a few of my clients devs have ssh access. The deployment method is to `git pull` (from github or bitbucket).
Any rouge Dev can just set up a direct ssh remote and push to pro.

It is possible to set up protection using the git hooks etc but that is obviously beyond them.

@hjk101 now I'm confused, you say there is no server, but the deployment is to pull from github or bitbucket, which are the remote servers aren't they 🤔

Github, gitlab, azure devops, or even (if you're particularly sadistic) bitbucket are usually configured to protect master, you need a PR to merge branches. Nobody should be able to push to master.

If the deployment is so unprotected that a dev can deploy from their local repo, at least the remote is protected so their fuck up can be undone

@nibor a lot of them do work that way. And usually need an incident to enable branch protection (always the same reasons. But we only with a few devs. We trust eachother. What if we need to fix something real quick). A few don't use central repos at all (ooh expensive, not safe and other bs).

I always try to push for fully integrated pipelines.

Nice thing about git is the distributed model. Hard to have it in a way that can't be undone even force pushes. As long a someone still has an un-fucked copy. Trouble is usually with the fucked up data not the code.