The main advantage I can think of is you can just configure your nightly expensive CI jobs (running absolutely all e2e tests) to run against a static branch.

Another might be that git clone gets the "correct" branch by default. Might be important if your git repo gets cloned by sales, support or whatever for external demo purposes.

Anyway I don't think it makes a huge difference in complexity - it's rarely used for developers' workflows and doesn't even need to be updated that often.

How meaningful is it to run build/test against a branch that is reflective neither of a release branch nor a feature branch, though?

For mobile apps and SDKs I found it very useful to keep a pointer to the current production version (master) for integration tests.

I don't really understand the distinction between develop and master either. You're supposed to branch off develop and merge forward back into develop, then merge into a release branch, then merge into master. So everything in develop is supposed to end up in master.

So... why not branch off master and merge back into master?

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...

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?

Master is current production version. Develop is current development version. You branch off develop to work on your feature, then you merge it back to develop so you have integration point with your co-workers (you fix conflicts here) which can be deployed to test server or just run through automated tests. When you have develop branch in correct state (whatever that means for your team) then you merge it into master creating new release on production.

This way in case of some unforeseen bugs you can fix master which is production like and then merge that fix also into develop so it is present in next release. If you would develop on master you don't have obvious "production like" place. You could do tags, but somehow it fits better with CI setup and Jenkins.

In our team we have acceptance branch instead of "release branch".

Feature branches are short lived, develop, acceptance, master are long lived branches. You also don't mix stuff because what you really want is one way direction of promoting changes develop->acceptance->master.

Yeah, I usually just have master(gitflow-dev) and release(gitflow-master). Works fine for me. Has the added benefit of git noobies not defaulting to the release branch they shouldn't just push to.

I fully agree. Removing the master branch which is just fluff that noone uses you essentially come to trunkbased development.

It's named "master" and people have become very superstitious about that name.

That's it, that's the reason.