I've been working with a customer to get some development infrastructure and procedures in place.
A problem we had was that, although we had got development branches, some developers were surpremely confident that their change definitely wouldn't break things, and so would regularly put some of their commits directly on the master branch; and then a few minutes later, the build robot would discover that things were broken on master. This was (is) bad because we were trying to keep master always ready to deploy; and trying to keep it so other developers could always base their new work against the latest master.
So we invented a new policy, and a tool to go with it, the fascist-push-master.
Basically, you can only put something on master if it has already passed the build robot's tests (for example, on a development branch).
This doesn't mean "your dev branch passes so now you're allowed to merge it to master" because often breakages happen because of the merge of "independent" work. Instead it means, that master can only be updated to a git commit that has actually passed the tests: you have to merge master into your dev branch, check it works ok there, and then that is what becomes the new master commit.
I wasn't so mean as to make the git repository reject unapproved commits - if someone is so disobedient as to ignore the policy, they can still make whatever commits they want to master. Rejection only happens in the client side tool. This was a deliberate decision.
The merge-to-master workflow previously looked like this:
git checkout mybranch # do some work git commit -a -m "my work" git checkout master git merge mybranch git push origin master # now the build robot tests master, with mybranch changes added
but now it looks like this:
git checkout mybranch # do some work git commit -a -m "my work" git merge master git push origin mybranch # now the build robot tests mybranch with master merged in fascist-push-master # which will either push this successfully tested # mybranch to master or fail
The output looks like this:
$ fascist-push-master You claim ba5810edfc67be5118be6c02ab3ffbe215bbe898 on branch mybranch is tested and ready for master push Checking that story with build robot. Umm. Liar. Go merge master to your branch, get jenkins to test it, and come back when it works. INFORMATION ABOUT YOUR LIES: BRANCHID=mybranch INFORMATION ABOUT YOUR LIES: COMMITID=ba5810edfc67be5118be6c02ab3ffbe215bbe898
The script is pretty short, and pasted below:
#!/bin/bash export BRANCHID=$(git rev-parse --abbrev-ref HEAD) export COMMITID=$(git rev-parse HEAD) echo You claim $COMMITID on branch $BRANCHID is tested and ready for master push echo Checking that story with winnie. ssh buildrobot.example.com grep $COMMITID /var/lib/jenkins/ok-commits RES=$? if [ "$RES" == "0" ]; then echo OK, you appear to be telling the truth. (git fetch && git checkout master && git merge --ff-only origin/master && git merge --ff-only $COMMITID && git push origin master && git checkout $BRANCHID) || echo "SOMETHING WENT WRONG. CONTACT A GROWN UP" else echo Umm. Liar. Go merge master to your branch, get jenkins to test it, and come back when it works. echo echo INFORMATION ABOUT YOUR LIES: BRANCHID=$BRANCHID echo INFORMATION ABOUT YOUR LIES: COMMITID=$COMMITID exit 1 fi