4

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.

|improve this question
  • Do you ever intend to roll the fixes from release 3 back into the main branch, or any other branch? – Robert Harvey♦ Jun 4 '18 at 15:01
  • @RobertHarvey Yes, we merge release 3 back into develop when necessary (e.g. if the changes need to be in develop in order for us to proceed with other develop work). We also do a final merge from the release branch back into develop when we release it to production. – Jacob Regan Jun 4 '18 at 15:07
  • @JacobRegan: it seems your master branch is always identical to either the last or next-to-last release branch. If that's true, the answer to the question is quite obvious: there is no real benefit in keeping two identical branches with the same name. – Doc Brown Jun 4 '18 at 16:27
  • Why do you need a release branch if you merge all of it back into master and don't release from the release branch? – RemcoGerlich Jun 5 '18 at 12:11
  • @RemcoGerlich I've added an edit to the question to explain why we use release branches. The reason we then merged from each release branch to master is that we were under the impression there must always be a master branch, this process didn't seem right hence the question. After seeing some of the responses it appears removing our master branch and releasing straight from the release branches is the correct solution for us. If this is not the case or I am missing something please let me know. – Jacob Regan Jun 5 '18 at 12:55
5

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.

|improve this answer
  • Thanks, this is helpful. 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. – Jacob Regan Jun 5 '18 at 8:15
  • @JacobRegan branching off master before release to facilitate testing is a great reason to branch, instead of just tagging the release; i.e. the testing would be done on the newly branched release branch, while development continues on the master for the next release. – esoterik Jun 5 '18 at 16:18
0

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.

|improve this answer
0

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.

|improve this answer
0

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.