This issue indicates that:
From my understanding placing the tag on the release branch before
merging (and not on the master branch) is in fact the correct thing to
do so it can be found by git describe –tags from the develop branch,
too. See #374
while another post:
I accidentally installed the 0.4.2-pre version via homebrew today and
was confused by the way the tagging works in that version. Previously
(version 0.4.1) the tag was created on the master branch, after the
release branch has been merged into it. Now it seems that the tag is
created on the last commit of the release branch, which seems not to
be a good idea for me. Especially if you have a build-system that
relies on git tags and creates a release version if HEAD is a tagged
commit and a development version if its one of the following commits.
Could someone explain the logic behind this change to me? And with
respect to semantic versioning I don't would consider this to be a
version bump in the patch-level!
In our team we have and had multiple discussions about this. Some indicate that a tag needs to be created from the master branch while others prefer the release branch. According to the gitflow picture:
it looks like that the tag is placed on the master.
Best Answer
Firstly, you can't tag branches, you can only tag commits.
You should tag the commit you actually release. That's the point of version-tagging commits. If you have an issue with your software in some environment (production or otherwise) you can say with confidence that the issue was introduced by the commit that that release was derived from.
(This is why people talk about 'reproducible builds': so they can be confident that their release process isn't introducing new bugs that weren't present in their preview/staging environment, and that if they have a bug in production the same binary is running on their machine when they go to debug it.)
There's no point tagging the second green commit from the bottom (the green child of the commit marked 'Only bugfixes!') as 'v1.0' because you didn't release that commit to production. You released the commit on master. You can even see that git flow has marked that as 'Tag 1.0'.
Remember, tags have a purpose: to easily find commits. You tag a commit as 'v1.0' so that you can easily find the thing that you released as version 1.0. You don't tag it for the sake of having a 'v1.0' tag somewhere in your commit tree vaguely near the commit you actually released.
If you have issues finding the tags from your development branch that's an entirely separate issue. Fix the tool you use to find tags. Or better yet: don't use git-flow. It looks nice in that diagram because of the lovely coloured dots and nicely laid out lines, but in reality it looks like an insane messy web of coloured lines and dots.