gitbranchgit-flowhotfix

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


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?


Solution

  • 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