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.
  • 12
    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

2 Answers 2


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.

  • 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. 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. Sep 11, 2017 at 19:14
  • That is what I am afraid of. It likely would open a scrollview with 5k entries. 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. Sep 11, 2017 at 19:16

Lots of things are possible. But using a namespace in order to store a single bit (builds/does not) is a “design smell”, in my opinion.

With a namespace you have to constantly come up with a unique name. Maybe a UUID? Or a to-the-second datetimestamp? That’s tedious to automate and look at. (Or not: you seem to be fine with the names.)

Instead you could annotate the commits with git-notes(1), like with the git-tests tool.

…If whatever tooling you need to use has support for the fairly niche corner of the git(1) suite that is git-notes(1). If not, git-tags(1) is after all completely ubiquitous; widespread use often beats perfect fit-for-use.

Or else you could store a list of all commits that pass.

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.