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?
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.
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 arelease1.1
tag on therelease1
branch.git config --add gitflow.multi-hotfix true This command seems to work for me!
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:
... make your fix, then:
or using
git flow
commands... make changes then: