Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also known as the "Not Rocket Science" rule: https://graydon2.dreamwidth.org/1597.html

When you're ready to merge, have CI test the result of the merge, and only push the merge commit if things pass. Don't let anyone other than CI push to master.

You can set up a bot with a queue to do this, of course, but you can also define "CI" as a shell script. GitHub, GitLab, etc. will automatically close a pull request if you push to master; you don't have to push the button on the website. Train people to not hit "merge" and instead to run a script, something like this which I just threw together:

    #!/bin/sh -e
    repo="$(mktemp -d)"
    git clone https://... "$repo"
    cd "$repo"
    git merge "$1"
    make test
    git push
    cd
    rm -rf "$repo"
If tests fail, it'll abort at "make test". If someone else pushed something, it'll abort at "git push" and you can just rerun the command, which will test the result of the latest merge. If you retry a lot, it's a sign your team is busy enough you should invest in setting up a real bot - not a sign that you should forego this property and land untested things on the develop branch and make yourselves deal with doing development on top of untested code.


I don't like the article - too many words, too many digressions. Also the chosen catch-phrase is poor.

As long as GitHub does it wrong, you won't be able to "train people" not to hit the big juicy green button, that should be really a big red "Emergency Merge - Can Break The Receiving Branch" button.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: