I’ve been thinking about the vulnerability of the primary Git branch for the last several weeks. Mostly out of paranoia about destroying a critical application. I added protective measures to my local clones on important projects and was content in thinking that I was now safe. But today I was reminded that this is only a small part of protecting a collaborative project.
Here’s what happened:
- User 1 made a commit on
masterand pushed to
- User 2 fixed a bad merge on branch
git push --force
- User 1 made a tag directly on the remote and deployed to Production
- User 1 saw the new tag in production, but the new commit was missing
The problem was introduced with the
git push --force. User 2 must have had a Git
push configuration of
default = matching. This is the default in Git version pre-2.0, but can still be set explicitly on newer versions. The result was that the intended
feature branch was force pushed, AND the
master branch was also force pushed!! Yikes.
We lucked out, as the newly deployed tag was identical to the previous tag and there was no production impact. But the result could have been much, much worse.
Here’s what we’re doing about it:
- Add local force push protection for the
masterbranch with a
pre-pushGit hook and push config enforcement
- Add protection to the
masterbranch of our Github mirror if possible
We already use a
git-setup.sh script to add a
pre-commit static code checker, so it should be pretty quick to add a
pre-push hook from the following Gist:
The one case this hook doesn’t cover is the exact scenario described above. In order to protect against this, we can add local Git configuration to ensure the default push behavior as anything other than
matching. My current preference is for
nothing, but really any of
upstream should work fine.
We use Github primarily for code reviews and mirror our repo there via Jenkins. It’s not clear whether branch protection is compatible with mirroring via Jenkins, so that’ll need some more research.