11

My team is using the Git Stable Mainline branching model and we are about to create the first release branch. From what I have read so far, it sounds like release branches are siloed from the master branch and never completely merged back to master. Instead, if a fix is made on the release branch, then it is usually cherry-picked back to the master branch. This makes sense to me since you would want to keep the current release completely separate from development of the next release, while still being able to develop the next set of features on master at the same time as getting the current release ready.

How long should these release branches be kept around for? Are there any cases in which they should be completely merged back into master?

Improve this question
5
  • 2
    The branching strategy you use depends entirely on your organization's workflow and specific requirements.
    – Robert Harvey
    Dec 4, 2017 at 15:55
  • How long should these release branches be kept around for?As long as you expect to receive an errormessage for that release that you want to reproduce from source-code. I would not remove any release branch at all because a branch has a small kilobyte-footprint on the server. only the delta costs harddisk memory
    – k3b
    Dec 4, 2017 at 15:57
  • 1
    cherry picking each and every commit on the release branch into master or merging release into master is technically the same thing accept that you don't "see" the cherry picks in the git history. So I'd prefer merging each fix back into master using gits --no-ffoption so that the history shows the extra release branch.
    – Timothy Truckle
    Dec 4, 2017 at 16:02
  • do you mean this : bitsnbites.eu/a-stable-mainline-branching-model-for-git he explicity says never to merge the release branches back
    – Ewan
    Dec 4, 2017 at 16:19
  • Thanks for the feedback everyone. @Ewan Yes, but I also read some general Git documentation written by Microsoft and it looked like they never merged the entire release branch back to master either.
    – user290137
    Dec 4, 2017 at 16:24

1 Answer 1

Reset to default
8

How Long should these branches kept for ?

The first answer that pops in my mind here is :

Why are you creating release branch in the first place ?

If you are aiming to be able to provide support to a version in production use then it should live as long as that version lives with your customers. (say LTS support, you could have multiple such branches, making things a tad bit more complex)

If you are separating stabilisation work from on-going new development then once the version is deployed you don't really need that branch anymore. Here this would hint at a continuous delivery pipeline. Any bugs gets their fix in the next release which would occur as frequently as possible. Some push this to considering the master branch as the stable branch deploying multiple times daily. Others will sync to their sprints and release every two to three weeks.

Should you merge it completely back into master ?

As you guess it all depends on why you adopted this branching strategy. for continuous delivery style, since the branch will never be used again then you should treat it just as you would any feature or bugfix branches, likely you would merge it back to the master and forget about it.

If however you are aiming for LTS style then you likely would not merge it back, especially if you have multiple such branches. Here you would apply the fix to all release branches and cherry pick from one of them to merge that fix back in master. In this scenario the last thing you would want to do is to treat it like any other feature branch where changes from master are pulled up into it and conflicts resolved there rather than in the master.

Without knowing more about your product life-cycle and your team's workflow it is difficult to come up with a more precise advice here.

Improve this answer
4
  • This implies that branch is lost after merging, which is not a case. Release branch should be merged in master in LTS mode too. There is no reason not to merge release branches.
    – Basilevs
    Dec 5, 2017 at 3:10
  • 1
    It's not about branches being lost but more about forcing one to think, systematically merging the LTS branch(es) would make them merge duplicates for every LTS branches that are active. A bug fix only needs to be merged back once to the main and likely not from an LTS branch as the most recent version would likely not be in LTS yet and would be closer to the state of the master branch. In this scenario one would cherry pick from the most recent version, LTS branch themselves would almost never be pushed to the master. That the branch is lost or not after a merge is irrelevant.
    – Newtopian
    Dec 5, 2017 at 14:46
  • Why would one prefer to duplicate unsafe cherry-picks to safe merge duplication? By "safe" I mean cryptographically protected change tracking and propagation.
    – Basilevs
    Dec 5, 2017 at 14:53
  • Similar approach works without cherry-picks by applying the fix to oldest branch and merging from older to newer. If cherry-picks can be avoided why use them? I seem to misunderstand something in Stable Mainline model...
    – Basilevs
    Dec 5, 2017 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.