Tags on incorrect commits

[jschmidtatet]

In the following situation:

release          A---B---D
                  \     /
hotfix-1.5.1       --C--

A = Release 1.5 on the release branch
B = Release 1.6 on the release branch
C = Hotfix 1.5.1 working branch
D = Merge of C into "release" branch (when running "git flow hotfix finish 1.5.1")

In this example, git flow would originally tag "D" with "1.5.1", but because this is the merge into release, the merge conflict resolution would favor the latest version number on release (whatever you updated when git-flow prompts you to "bump the version number"). That means checking out the tag "1.5.1" would give you files that contained "1.6" changes as well as had the version number "1.6". To get the "real" 1.5.1, you would have to check out the second parent of the merge "git checkout 1.5.1^2" which is something that would be annoying to have to remember at best, and could be very detrimental if forgotten (for example, if you need to rebuild a 1.5.1 here, and checked out 1.5.1, you wouldn't have the same code as was originally built before running git-flow-hotfix finish).

Instead, we want the tag "1.5.1" to point to "C", but the merge "D" to still be created.

[vStone]

Is there a way to NOT tag on the (release) branch but still on the master branch? I would like to see all tagging (if possible) for major releases on the master branch.

[mruoss]

But where should the tag be located when finishing releases? I'd say the master branch should be tagged, right? No the release branch.

[WORMSS]

Yep, I agree, Tagging the master branch is the behaviour I would expect after reading the Nvie "A successful Git branching model" document. The picture shows it on the master branch.

http://nvie.com/posts/a-successful-git-branching-model/