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

Solution 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

Solution 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.

Solution 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.