This question is related to Vincent Driessen’s Git Flow branching model.
To better describe my problem I would like to use one of Mr. Diressen’s great pictures in a slightly modified way:
The important point here is that there are the releases 1.3.0 and 1.4.0. The situations comes that 1.2.0 needs a fix which would result in the version 1.2.1.
What I don’t understand how to merge from hotfixes back to master but between the 1.2 and 1.3.0 commits?
1
You don’t want to inject these commits on master between the commits and tags for 1.2 and 1.3. Although you can rebase, introducing commits like this is a form of rewriting history and could introduce problems for other people with the branches locally.
This exposes a flaw in the git-flow model.
One of the stated use cases for the git-flow model is cases where “you need to support multiple versions of your software in the wild”. To do this without rewriting history, you need to have long-lived release branches. You cannot remove the release branch until after the release is no longer supported, since any techniques needed to inject the commits and tags into the master branch may cause serious problems.
Since the solution is to keep your release branches until the release is no longer supported, my recommendation would be to have release branches for all supported major and minor versions. That is, you would keep release-1.2, release-1.3, release-1.4, and release-2.0 branches, but you would never keep a release-1.2.1 or release-1.4.3 branch.
Since your release branches are now long-lived, you can create your hotfix branch off the release branch instead of the tag. You can develop the fix, test it, and then merge it into the release branch. From here, you can build and deploy the system.
If the same change is needed in multiple release branches (including in develop for the next release), you could cherry-pick the commits. However, this isn’t always possible if the changes needed are different. When you have multiple supported versions, you may need to make the fix multiple times and release different patched versions to make the correct change in each supported version. This depends on the nature of the problem you were fixing and the changes needed to fix it.
1
As an alternative to keeping the release branches around, as described in the answer by Thomas Owens, some people extend the git-flow model with long-lived support branches.
A support branch would be created from the tag of the 1.2 release when the first hotfix on that version is needed and will collect all the hotfixes on the 1.2 version and the associated release tags.
1