GitFlow: what is difference between release and master branches?

Question

I've just took a look on this gitflow cheat sheet. I don't understand the release branch.

Could anybody tell me the difference between release and master branches?

Answer 1

The difference is in goals and process. A release branch is usually created when you are preparing for an upcoming release. When all your feature branches which are supposed to be released have already been merged to develop branch you create release branch off develop branch and commit only bug fixes or some configuration changes to it. In other words you try to make it as stable as it's possible. When hopefully release branch is stable enough you merge it back to develop and master branches. The purpose of master branch is to always have the latest stable version of the project which can be deployed to production environment. You never commit directly to master branch, only merge to it from either release or hotfix branches. It is also possible to configure CI/CD tools to deploy to production on any update in master branch.

Answer 2

Once all the features you want to have in your release are in develop, instead of "locking" develop to any new commit, you create the relase branch that will contains all the feature expected in your next release (and not in master since your whole release should be tested and would probably have some bugfix...).

• In this branch you have only bug fixes, documentation etc... but no new feature
• your develop branch is not locked up, so new features for the next release can still be commited/push on develop and tested.
• release branch is perfect to be deployed on staging/pre-prod environment and let QA test your release.
• Once release branch is stable, you can merge it into master and go to prod. Master should always be stable and steady (if not you make hotfix).

You can have a look at these links for further explanations:

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow http://nvie.com/posts/a-successful-git-branching-model/#feature-branches

Answer 3

I think your question comes from a misunderstanding of GitFlow that I often see. So it is worth debunking it.

In GitFlow release branches are short-lived. They are used to prepare a release. The benefit of the release branch is it makes it possible for one team to polish the current upcoming release while another team continues working on features for the following release(s). In contrast the master branch lives forever.

In GitFlow you do not release to production environment from the release branch. That is not what the release branch is for. The misunderstanding probably comes from the name "release branch". The master branch must reflect actual production worthy releases. You merge your release branch into master and you then release (i.e. creating artifacts) for production environment from the master branch. Artifacts meant for production environment always originate from master branch in GitFlow. You cannot have artifacts in production environment from any other branch. In essence every merge into master is a new official release in the GitFlow model.

The release branch goes away again once the release is over (once you've merged it to master) and I for one find it catastrophic to release into production environment from a branch which is deleted shortly thereafter.

The above seems to be controversial for some. But I think this is the classic GitFlow idea as described in the original paper. You'll find some who actually create build artifacts out of their release branch and they then put that into production environment. When they see it works they'll go back and merge it to master too. (or they'll forget this step). I don't think that is GitFlow.

A workflow where artifacts deployed into production environment are from another branch than master simply isn't GitFlow. It may be a good workflow for some, it may have its advantages, but it ain't GitFlow.

So in short this is classic GitFlow where you can clearly see the difference between a release branch and the master branch:

1. Prepare release on a branch named release/<something>.
2. When ready to ship : merge the release branch into master. Then delete your release branch (it no longer has a purpose).
3. Tag master with a version number, for example 5.9.1.
4. Create deployable artifacts from the tag on master. You now have a release (potentially for production environment). You now test those artifacts in all your environments: test, staging, etc. If it fails testing (despite the testing you've done before you merged to master) then you must accept that you now have a release 5.9.1 which goes in the wastebasket. Live with it!. You must then start over with a new release branch, for example release/5.9.2.
5. You can finally put the tested artifacts into production environment. If it turns out there's a problem in the production environment with the new release (despite all the testing) then again you must create a new release. This means you start over with either a new release branch or you follow the hotfix workflow model.

As can be seen, in GitFlow once you merge to master you've probably already done a lot of testing so that the risk that the release created from master will fail in testing is slim.

Note that GitFlow of course doesn't prevent you from creating artifacts from all the other branches than master and deploy them for testing purpose to any environment, except production environment.