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?

possible duplicate of [Git-flow and master with multiple parallel release-branches](http://stackoverflow.com/questions/16562339/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] — danio, Jun 23 '14 at 09:15

score 81 · Accepted Answer · answered Oct 10 '15 at 09:20

81

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

answered Oct 10 '15 at 09:20

Klas Mellbourn

35,589
18
119
143

?keep these support branches or deleted them after some period – Evan Hu Mar 01 '17 at 09:08
@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. – Klas Mellbourn Mar 01 '17 at 13:26
One should do a release on the hot fix, right? How can we do that? – Ravindranath Akila Jun 14 '17 at 07:30

score 34 · Answer 2 · answered May 05 '13 at 16:16

34

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.

answered May 05 '13 at 16:16

Andomar

216,619
41
352
379

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? – Klas Mellbourn May 05 '13 at 16:21
3

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. – Andomar May 05 '13 at 16:25
GitFlow supports tracking more than one produciton version: https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches – Andre L Oct 06 '16 at 11:21

Bert F · Answer 3 · 2013-05-05T18:35:28.763

7

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.

edited May 05 '13 at 18:35

answered May 05 '13 at 16:21

Bert F

78,021
11
97
121

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. – Victor Yarema Aug 02 '16 at 13:09

score -1 · Answer 4 · answered Dec 20 '18 at 16:53

-1

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

answered Dec 20 '18 at 16:53

Laila

1

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

4 Answers4

Linked