Following git-flow how should you handle a hotfix of an earlier release?

Question

If you try to follow the git-flow branching model, documented here and with tools here, how should you handle this situation:

You have made a 1.0 release and a 2.0 release. Then you need to make a hotfix for 1.0. You create a hotfix branch off the 1.0 tag and implement the fix there. But what then?

Normally you would merge to master and put a 1.1 release tag there. But you can't merge 1.1 to a point after 2.0 on master.

I guess you could put the release tag on the hotfix branch, but that would create a permanent branch beside the master that would contain a release tag. Is that the right way?

Schnorkle

possible duplicate of Git-flow and master with multiple parallel release-branches [although the other question is newer it has more useful answers so I have flagged this question as duplicate] – Jasik

Answer 1

It seems that there is a concept of a "support" branch in git flow. This is used to add a hotfix to an earlier release.

This thread has more information, with these examples:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... make your fix, then:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

or using git flow commands

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... make changes then:

git flow hotfix finish 6.0.1

Schnorkle

?keep these support branches or deleted them after some period – Boche

@EvanHu well, for sure keep them as long as you have that branch in production somewhere. After that it is a matter of historical record. You might want to know how hotfixes were fixed if they should ever recur. – Schnorkle

One should do a release on the hot fix, right? How can we do that? – Mnemonics

Answer 2

Interesting question! The flow you linked assumes master can track production. That only works if production versions are strictly increasing. That's typically true for a website which has only one production version.

If you have to maintain multiple production versions, one branch to track production is not enough. A solution is not to use master to track production. Instead, use branches like release1, release2, etc.

In this approach, you may not even need a hotfix branch. You could fix the problem on the release1 branch. When the fix is good enough, create a release1.1 tag on the release1 branch.

Certainly

You could change git-flow to setting the release tags on the release branches. That's a fairly major change. It would break the current scripts. Also, what would master then contain? – Schnorkle

The git-flow tooling is not suitable if you have to support multiple production versions. In the workflow proposed in this answer, master is not used at all. You could name the development branch master, it's just a name, after all. – Certainly

GitFlow supports tracking more than one produciton version: gitversion.readthedocs.io/en/latest/git-branching-strategies/… – Mump

Answer 3

git-flow assumes your are only supporting one release line at a time, conveniently tracked by master. If you are maintaining more than 1, then you will need to modify git-flow process to have multiple trackers of your separate releases you are supporting (master-1, master-2). You could continue to use master to track the most recent release line, in addition to or in lieu of a specific tracker for the most recent release line (master in lieu of master-2).

Unfortunately, any git-flow tooling you may be using will probably need to be modified, but hopefully you are familiar enough with git-flow process to handle this specific case directly with git commands.

Piezochemistry

If you modify git flow process then it will be something different. If some model should be fixed (not just extended) then it is as successful as its author states. Please check out my answer to the topic we are discussing. – Maquis

Answer 4

git config --add gitflow.multi-hotfix true This command seems to work for me!

Grip