Do we really need a master branch or can we release straight from a release branch?

Question

Currently we have the following branches:

• Develop
• Release 1
• Release 2
• etc..
• Master

When we want to cut off new features for a release, we create a new release branch (say release 3). We then only apply bug fixes etc. to the release branch and no more major changes.

When release 3 has been tested and everything is ready, we lock down Release 3 from further changes then merge it into master and release master into production.

My question is, do we really need a master branch? Why can we not release straight from Release 3 into production.

It seems merging into master first only adds more work and extra risk/testing requirements to ensure we did not do a "bad" merge from Release 3 to Master.

The other perceived benefit from my point of view is releasing straight from the Release 3 branch means that if something goes terribly wrong and we decide to rollback, we can simple re-release the Release 2 branch into production, then continue making fixes on Release 3. This seems easier than having to rollback master.

I've tried looking this up but have only found information on what the difference between release branches and master branches are, but not much on if/why we need both of them.

Edit: The reason we normally keep multiple release branches is that we often end up with 2 or more "release-worthy" sets of development that are ready for the testing phase. E.g. The testing team might be working on Release 1, and development have just finished the Release 2 work. We do not want to merge the Release 2 and Release 1 work together because the will effectively restart the testing phase and prolong the release. So instead we create a new release branch for the release 2 work.

Answer 1

Do we really need a master branch?

I think this is a structural/naming thing. It seems that upon release your release and master branches are identical. This would imply it's not necessary for releases.

It seems your project uses branches slightly differently than the canonical way. Nominally you have a master/release branch, and releases get tagged. Developers make branches to add features, fixes etc. and then merge their branches into the master so it can be used for release.

Then when a bug occurs that needs to be applied to an old release, a new branch is made for that release based on the tagged version, the bug fix is made, merged, what have you, and then a new old version (point release) is made for those still using the old release.

If you don't intend to roll fixes back into old releases, or simply don't support them, then they aren't necessary at all, hence the normal way creates them on demand, it seems you create them preemptively. So in your case, No you don't really need a Master branch, though it seems what you really don't need is the release branches, until you need to pull changes into them.

Answer 2

It depends WHY you have a master branch. I would run a git diff to see what the differences are between master and the latest release. Understand that, and you can understand what would have to change to get rid of it.

For example it may be that the difference between master and release branches is that production credentials are maintained in the master branch. If so, then you can't get rid of the master branch without having another way to add those credentials in only in a production environment.

Answer 3

This sounds like you have been following git-flow, and are looking for something simpler. I think most teams should use something simpler than git-flow. I would agree that you don't need the 'master' branch. You can delete it, and then may want to consider renaming the 'develop' branch to 'master' or 'trunk'.

That gives you something like the the 'Branch for release' strategy described on the Trunk Based Development website.

Answer 4

To some extent, you can do this as you like. At my place there I ONE iron rule: We release something that is in git ( not on a developers machine) and tag it, so we can get that exact code again in a few years. That is the one rule that must never be broken, everything else is secondary.

Secondary is: At certain points, we merge a release branch to the master branch, which is very rare and must happen without any conflicts. You can do that as you like.