31

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.

Improve this question
4
  • 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
    Commented Apr 21, 2017 at 15:09
  • 'The gitflow' implies that this (IMO poor) workflow is the standard or official git workflow. It isn't.
    – mrr
    Commented Apr 25, 2017 at 22:57
  • 1
    @MilesRout What is your favourite git workflow?
    – 030
    Commented Apr 26, 2017 at 7:08
  • for my case I use values of git tag to name the version of the app when release, so I make it in the release branch.
    – Phong Nguyen
    Commented Jul 12, 2019 at 2:28

1 Answer 1

Reset to default
28

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.

Improve this answer
5
  • 5
    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
    Commented Apr 26, 2017 at 7:06
  • 2
    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
    Commented Dec 21, 2018 at 18:23
  • 1
    Agree with taging the commit you release, but in some environments/businesses, you merge in master only after deploying in production and production has been proven to work and not require a rollback. See: stackoverflow.com/questions/47739701/…
    – Hans Deragon
    Commented Apr 20, 2020 at 14:48
  • 2
    Suppose you tag the merge commit on master: what commit would you use to build your release? If you build your release based on the merge commit, it means that you're re-building a different version of your code that you did not test on the QA environment. If you tag the last commit of the release branch, instead, you can just deploy that build directly to production knowing that you tested the exact same thing. I see a sort of conflict between the "build-once, deploy-everywhere" approach and this GitFlow tagging approach.
    – Kurt Bourbaki
    Commented Dec 15, 2023 at 15:56
  • 1
    @KurtBourbaki Yes I agree, it's not really ideal. But that's how this system works. The content of the commit on 'master' should be identical to the content of the commit at the end of the release branch anyway - there are no intervening commits on the 'master' branch except the 'hotfix' commit which was merged into 'develop'. So in theory, it should be fine. But in practice, it's another reason that this methodology has fallen out of favour. It looks nice in the pictures, but in practice it ends up being a mess of merge commits. Linear/near-linear workflows using 'rebase' are superior IMO.
    – mrr
    Commented Jun 16 at 3:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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