10

Currently we are using a tag for every build on master which passes CI. This leads to a lot of tags (3-10 per day). The good side is, that those commits are easily human readable, show the version (v.X.Y.ZZZ) which is also shown in the .exe built and deployed of that very commit making it very easy to find the exact commit a specific .exe was generated when bugs are reported.

  • Is this bad practice?
    • If it is, is there any better way?
    • If it is not, is there any way to remove all tags before some specific minor version? Currently when we delete those tags by hand this just leads to someone else repushing them, leading to an endless ping-pong effect.
Improve this question
1
  • 9
    You ask if this is a bad practice. Are you experiencing any problems with this practice? If so, what problems are you experiencing?
    – Thomas Owens ♦
    Sep 11, 2017 at 18:29

1 Answer 1

Reset to default
15

In practice, because every commit in a git system already has a hash, if all you need is a unique identifier to reproduce a build, or identify a particular state of your branch, you already have that with the commit hash. And obviously your CI system already knows that commit hash. So in this sense, all of those tags are a bit of a waste.

Is it bad practice? I haven't seen anything that would say it's bad, and I can't think of any real problems this will create, but it does seem quite unusual to me. Typically tags are used for releases, and the tags are semver'd. As long as you're semver'ing every tag, it's probably not terrible. Supposing that you actually deploy these builds, maybe it's marginally more useful to identify builds and their associated problems by tag rather than by git commit.

Your usage though seems to fall for me into a very large category we call "personal preference". I doubt the world will burn down if you keep doing it. It wouldn't be my choice, but if your build pipeline isn't broken, I wouldn't recommend "fixing" it to some ethereal state of git perfection.

Improve this answer
4
  • 1
    Yeah, in our CI system we obviously have this information already. I feel like the visual git clients do not support that many tags so well, the visual git commit log usually looks awsome with sem'ver tags but the tags view gets pretty long. What I'd like about the tag version and why I introduced it, is that you immediatly see if a merge-commit failed tests or builds after auto-merge - which does happen - because it does not get a tag. You do not even need to open the CI system, you immediatly see the last versioned commit to branch off your feature branch.
    – Kevin Streicher
    Sep 11, 2017 at 19:13
  • 1
    Because I haven't seen tags used like you're using them now, I've never really tested git clients myself, what happens when you have 5k tags? But because tags are a flat list structure, I probably wouldn't try it myself.
    – FrobberOfBits
    Sep 11, 2017 at 19:14
  • That is what I am afraid of. It likely would open a scrollview with 5k entries.
    – Kevin Streicher
    Sep 11, 2017 at 19:16
  • 1
    Then I think you have your answer, because tagging like you're doing now is sure to lead that way, and it isn't strictly necessary considering you have the commit hash.
    – FrobberOfBits
    Sep 11, 2017 at 19:16

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.