Hacker News Reader

Comment by kubanczyk | Hacker News Reader

There is a small trade secret, that's hard to visualize. If you merge two changes into master you can break it.

The fact that a change passed a CI and another change passed a CI doesn't mean they can merge and the result is guaranteed to pass CI. It will often break and if you think for a minute you will come up with really rudimentary examples of this.

The really primitive solution is to call the merge-recipient branch the "develop" and only merge to "master" when you are sure what you are merging is good. You'll be ok if you do it sequentially (no parallel merges to master).

A more complicated solution is to actually test (in CI) "what happens when I merge this" but in hiding, without showing it to others. Even more complicated is to do it in parallel. Gitlab calls it Merge Trains (Premium only). Zuul-CI calls it gate/gating and has a pretty good description here: https://zuul-ci.org/docs/zuul/discussion/gating.html#testing...

View on HN

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.

So always rebase onto master and test your rebased changes before you can advance (sigh, "fast-forward merge", in the parlance of our gits) the master ref to your changes. I still don't see the need for two separate branches.

This is true. Another explanation could be a two stage testing process. The CI test for develop might run quickly in a few minutes, but the test suite for master might run for a day or require manual testing.

Manual testing is an important thing to consider, for sure.

Who does QA on the feature branches, and where? Does each feature branch have its own corresponding deployment? Are they sharing databases with other branches?

Reply on news.ycombinator.com