65

I'm trying to choose a Git workflow that is most appropriate for our product. Here are the parameters:

  • We do a few major releases a year, let's say 10 at the most
  • We have multiple versions of our product active at the same time (some people are on v10.1, some on v11.2, etc.)
  • We need to be able to work on multiple releases at the same time (so we could be working on v12.1, but as we get to the end of the release we start working on v12.2 at the same time)
  • We need to be able to hotfix releases when critical bugs are found

So far, here's the way I think it could work:

  • Single remote repo is used
  • Create branch 12.1 from master
  • Create feature branches based on 12.1, commit them and merge back into 12.1, push
  • Once we need to start working on future release, create a new branch 12.2 based on 12.1
  • From then on, when working on a feature for 12.1, create branch from 12.1, commit changes, and merge into both 12.1 and 12.2, push
  • If working on a feature for 12.2, create branch from 12.2, commit changes, and merge only into 12.2, push
  • When release 12.1 is completed, merge it into master and tag master branch with 12.1
  • If a hotfix is needed, create a hotfix branch from oldest release branch that needs it, commit changes, and merge back into all release branches for that release and future releases that could be affected; if the latest stable release branch was affected, merge it into master.

I have a few concerns:

  • I'm not sure that merging hotfixes from old branches into new branches will be a smooth process, especially if there have been a lot of overlapping changes; would it be smarter to just hotfix manually in each branch in cases where it looks like there will be conflicts
  • The workflow models I've seen seem to not keep release branches alive much, once done the release gets merged into master, tagged, and removed. My problem with that is that I don't have a good idea how to manage the state of the release if all I have are tags in master, seems easier to hotfix in a branch and then I have a release I can always go back to that has the latest hotfix (I can even tag the hotfixes in the release). Not sure there's a way I could go back within master and somehow have a copy of the release with hotfixes applied and update that tag.

Comments are appreciated on things I may have overlooked or better ways of accomplishing things given the requirements I've specified.

Improve this question
5
  • 4
    nvie.com/posts/a-successful-git-branching-model Commented Jan 16, 2015 at 16:50
  • 26
    I'm aware of git-flow, but I don't see how it addresses working on multiple simulataneous releases. Seems like release branches aren't even really made to do any work on, mostly to do cleanup and then merge and tag. What do I do when I have a hotfix that affects 4 different release versions? I guess I could checkout a tagged release from master, but once I've made fixes to it, how would I re-work whatever fixes I've made into master for that particular release. Seems like it would be rather difficult. Commented Jan 16, 2015 at 17:37
  • 4
    If you need to hot fix multiple releases with the same fix, you should probably fix the oldest version first and merge up to newer, adapting to fit for each release. If you work from new to old you risk pulling down dependencies from later releases which will complicate things. Commented Feb 29, 2016 at 4:55
  • And as I mention in my proposed answer, the master branch doesn't work so well with multiple live releases, so unless you really need it for some reason, I would advice you not to use it. Commented Feb 29, 2016 at 4:57
  • When you say your consumer base is on multiple versions, do you mean that you have multiple instances, each sporting one specific version, or do you have one instance that sports multiple versions at the same time? They are two distinct scenarios, each with their own challenges. Commented Sep 16, 2024 at 5:26

5 Answers 5

Reset to default
28

You seem to be branching off on every major release (12.0.0), then having possible minor updates to each (12.1.0), and hot fixes (12.2.1). Correct?

There's no specific reason why you cannot keep release branches alive in GitFlow after a release is out, other than the fact that coordinating changes between multiple diverging branches for a long time is hard with any model. I suppose GitFlow was also modeled more for products that maintain a single live release while developing the next.

I would stick with GitFlow and make a few amendments;

Skip the master branch. I've had no practical use of it so far, and it would lose its linearity the way you work. Keep development on the next major release on develop. If you decide to keep master, don't put release tags on master, put them on the last commit on the release branch that produced the binary you're shipping.

Don't throw away the release branches after you merge them back to develop. Instead keep them around for the next minor release and possible hot fixes. If you ever stop supporting a release, I suppose it's fine to delete them. You could name release branches after their main component, release/12, and then create sub-release branches, release/12.1, release/12.2 off of it. I've not had to worry too much about this level of parallelism, but that's probably what I'd try. You can think of each major release branch as its own sub-GitFlow environment in this case.

If you must be working in parallel on features for several future major releases at the same time, perhaps you have to keep the next one (13) on develop and anything for later versions (14, 15) on additional "develop-N" branches. That does seem very hard to maintain in general, but would be possible.

Improve this answer
2
  • 1
    But if you're maintaining a single release, then you don't need other branches anyway. Just the master branch. So there's no point in using git-flow then... Commented Aug 11, 2023 at 6:01
  • I don’t understand why you mention that you can use Git Flow then say get rid of master. That’s an effective rename of master to develop. And then just keeping the release branches. Well, the final result here looks like Git Flow except develop is changed to the release branch for each release. Commented Sep 13, 2024 at 15:46
5

It seems that a possible solution for your main problem («We need to be able to work on multiple releases at the same time [...]») is dooing a git worktree add <path> [<branch>]

A git repository can support multiple working trees, allowing you to check out more than one branch at a time.
With git worktree add, a new working tree is associated with the repository.

This new working tree is called a "linked working tree" as opposed to the "main working tree" prepared by "git init" or "git clone".
A repository has one main working tree (if it's not a bare repository) and zero or more linked working trees.

See this SO answer for a detailed introduction on git worktree.

Improve this answer
1
  • 1
    Git Worktrees is a tool for having multiple branches or snapshots checked out in different directories at the same time. The question is about branching strategies. This doesn’t address the question. Commented Sep 13, 2024 at 15:47
3

You mentioned that you are familiar with gitflow. I suggest to addopt it for your scenario. You will need to create branches from your development branch to support older versions. These older versions will also need to have their own release/master branches and hotfix branches. You will need to periodically merge your support branches into the newer support branches and the develop branch.

As the development of the major versions diverges this will keep getting harder. There is no silver bullet for this. Sometimes it will be easier to make changes manually. The cost of maintaining the older versions will increase, and at some point it won't worth it anymore.

It all depends an what kind of changes you are making in your older versions. If only bugfixing, thats relatively easy to merge. If you try adding new features, that will be hard.

Improve this answer
2
  • But as I mentioned, in the case of git-flow it doesn't seem like they use release branches for much at all. It didn't sound like there's any major development that goes on there. It also seems like the develop branch is kind of useless if we're mostly working in release branches, might as well just get rid of it, each release branch is essentially a develop branch for a certain period of time. Or am I missing something? Commented Jan 19, 2015 at 17:12
  • "each release branch is essentially a develop branch" No it is not. In a git flow model ideally you do NOT add features to a release branch, only bug fixes. Commented Dec 11, 2019 at 10:05
2

I’ve been looking at “A stable mainline branching model for Git” which I think has the potential to solve this problem nicely.

To summarize:

  • Single branch for development (master). Features branch from master and are merged back to master
  • When master is stable and ready for a release, branch off to e.g. release/1.0 and tag the commit as a release candidate
  • QA the release branch
  • Make updates and new release candidates as necessary on the release/1.0 branch
  • Eventually tag v1.0.0
  • Never merge release branches back into master
  • Meanwhile, feature development has not stopped on master for the next release
  • Hotfixes are ideally made on master and cherry-picked to release branches. If that’s impossible, hotfixes can be made on the release branch itself and a ticket should be made to fix the problem properly in master.

visual depiction of branching model as described

The article has a lot more detail about different scenarios with this model and how to solve them.

Improve this answer
0

A branching model or strategy should be as simple as it can be while still supporting your current use cases. To that end we need to start with a simple strategy and only make it more complex as the need arises.

The simple case: GitHub Flow

There is one eternal branch. We can call it master.

  • All feature branches are created from master and merged back into it
  • When a version is to be released tag that commit

How this relates to your strategy

The way you describe your branching is already like the above description, only with more branches:

  1. About to start work on a new version: make a branch for that
  2. Feature branches start from this branch and are merged back into it
  3. “When release X is completed, merge it into master and tag master branch with X”

Notice that there are no points where you might merge into master instead of the release branch. So master never gets updated. This in effect means that this new release branch effectively works like master until the final release.

And the crucial step is (3): the release branch is merged into master and then tagged (released). Thus for the release itself (the tagged commit) it made no difference that you created a new branch for the upcoming release.

So the release branch is just one more thing to manage. Both for the person who manages it and for all the people who have to keep in mind to branch off of that new branch.

But there is one chink in my explanation here: you create the next release branch from the previous release branch before the release of the first version (12.1 vs. 12.2). Now we might get into a legitimate need for a dedicated release branch. But on the other hand I can’t quite make sense of it. Why start a release branch the branch of 12.1 (yet to be released)? It seems random. You’re effectively starting the release branch of 12.2 from some spot in between 12.0 and 12.1.

The need for release branches: diverging master and the upcoming release

In general: there is a need for a release branch if the eternal master branch and the release branch might diverge. Concretely:

  • You have four pending feature branches which you want in master
  • But two of them are risky so you don’t want them in the upcoming release

Hence you will get a divergence: master will have something that you don’t want in the upcoming release.

And here is where you can create a release branch. Let’s call it a “release candidate branch” (RC) so that I don’t get confused between the final release and work-in-progress towards the release.

And this is the time to make the RC branch 12.1-rc from master.

Now you can merge in the two safe things into 12.1-rc branch. Let’s say this happens over a few days:

  1. Risky 1 is merged into master
  2. Safe 1 is merged into 12.1-rc
    • And RC into master to keep master up to date
  3. Risky 2 is merged into master
  4. Safe 2 is merged into 12.1-rc
    • And RC into master

In this way your development can contiue as normal without interrupting the upcoming release. Meaning you can pick and choose what goes into the next release.

Then after 12.1 is released you can merge the RC branch into master or the other way around (this depends on what kind of first parent merge history you want). Delete the RC branch.

Updating releases

As we have discussed: only create as many branches as you need. Sometimes you won’t need a release candidate branch. And you might not need to update a release.

But say there is a bug in 12.1. You don’t want the installations that are on this release to get the next upcoming version yet (say 12.5). So create a branch from that tag, maybe 12.1.1-rc, do the hotfix and release it.

Updating later releases: backporting

You already explained a great strategy for backporting fixes:

If a hotfix is needed, create a hotfix branch from oldest release branch that needs it, commit changes, and merge back into all release branches for that release and future releases that could be affected; if the latest stable release branch was affected, merge it into master.

Exactly: the fix goes to the oldest release and is propagated forward as needed. Do you have four other releases that need this one as well? Back-merge them upwards. Then finally merge the latest merge to master. Or perhaps you don’t need to update any more releases? Then back-merge directly to `master**.

Just delete branches that are no longer needed

The workflow models I've seen seem to not keep release branches alive much, once done the release gets merged into master, tagged, and removed. My problem with that is that I don't have a good idea how to manage the state of the release if all I have are tags in master, seems easier to hotfix in a branch and then I have a release I can always go back to that has the latest hotfix (I can even tag the hotfixes in the release). Not sure there's a way I could go back within master and somehow have a copy of the release with hotfixes applied and update that tag.

You don’t need to keep around branches that are not in use.

Say you release 12.1. There might be no issues with it. And if there are? Create a branch from that tag.

Improve this answer

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.