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:

enter image description here

it looks like that the tag is placed on the master.

  • 1
    I know GitLab struggles with tags on branches when you prune older branches away, so it'd be better if the tag were on the master. Not sure about other git tools. – HorusKol Apr 21 '17 at 15:09
  • 'The gitflow' implies that this (IMO poor) workflow is the standard or official git workflow. It isn't. – Miles Rout Apr 25 '17 at 22:57
  • @MilesRout What is your favourite git workflow? – 030 Apr 26 '17 at 7:08

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.

  • 1
    You should tag the commit you actually release. So if for example 20 commits that need to be released reside in the release branch and this branch is merged into the master, the merge commit that has been created has to be tagged in order to know what has been released? – 030 Apr 26 '17 at 7:06
  • Yes, the merge commit would be tagged. As a variant of git-flow, I've also seen creating/tagging a separate "version bump commit" directly on branch:master – rmharrison Dec 21 '18 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.