8

I've read Git branching and tagging best practices and git tagging comments - best practices, but I don't see a direct answer to something I've wondered for a long time:

Why does Git have tags? (instead of just branches)

They seem to be second-class citizens, or at least "different." They aren't pushed unless you specify that explicitly. Deletions of remote tags doesn't cause deletion in downstream repos.

This last point was a problem recently, as someone pushed a bunch of garbage tags with tons of commits from another repo. We could delete them upstream and gc the commits, but that wouldn't propogate, and the next time someone pushed a tag with git push --tags, they'd repush those garbage tags and commits. So we had to make sure everyone deleted them.

When and why would I use a tag instead of a branch?

  • 1
    For one thing, tags can be annotated, branches cannot. Tags are generally "permanent" things (typically for marking specific versions of a project). – Rufflewind Jan 23 '15 at 5:40
10

This is done on purpose.

They seem to be second-class citizens, or at least "different." They aren't pushed unless you specify that explicitly. Deletions of remote tags doesn't cause deletion in downstream repos.

I don't agree with lxrec's answer about git having bad defaults. If you follow the mailing list, you can see that git developpers actually care about having sensible defaults. Would it make sense to have --ff-only as a default? I don't think so.

Tags make it possible to have annotations for your own, local development copy. I would not like to see my why_does_it_break_here and todo_fix_formatting tags being pushed without my consent (those are not actual tag names). Tagging a release, on the other hand, is something that occurs less often, and it makes sense to require an explicit push (or use an alias).

I don't see a major difference between tags and branches w.r.t. how push/fetch behaves. In your example, if the garbage tags had been branches, would the deletion propagate as you intended?

When and why would I use a tag instead of a branch?

Generally speaking:

  • branches are for trees: they point to different commits over time
  • tags are for individual commits and are immutable (this includes frozen trees such as releases)
  • Aren't annotated tags and signed annotated tags (i.e. the ones that one would actually use for, say, tagging a public release) pushed by default? It's only non-annotated "local" tags that aren't pushed by default, because, well, as you said, they are local. – Jörg W Mittag Jan 23 '15 at 10:56
  • @JörgWMittag I didn't check, but I trust you on this. Wait a minute, that would mean, that git has sensible defaults?! – coredump Jan 23 '15 at 13:23
  • @JörgWMittag So, I tried locally with two repositories in different directories, and neither annotated tags nor annotated+signed tags where pushed. This is with git 1.8.2. – coredump Jan 23 '15 at 13:41
  • Ah, wait. I thinks it's annotated and signed tags get pushed automatically with git push --tags, but local tags don't. It's been a while since I used git in anger, that was way before Git 1.0. – Jörg W Mittag Jan 23 '15 at 16:08
1

1) Why are git tags second-class citizens?

Because sadly, git has a lot of bad defaults. As much as I like it, it simply is not a very newbie-friendly or intuitive tool. Pretty much everyone has to set up git configs or aliases or scripts that use a dozen or so of the -- options (like --ff-only) to make git start behaving the way they actually want it to. Tags are just one more example.

2) Why would I use a git tag instead of a branch?

A branch is intended to mark a commit that you make other commits on top of. When you make a new commit to that branch, the branch itself "moves" so that it points to the new commit.

A tag, on the other hand, marks a commit, and then keeps marking that same commit pretty much forever (in theory). The most common usage is tagging commits with their official release versions every time you roll out a new version to production.

We use both branches and tags for our release versions. The branch merely represents major/minor version, while the tags specify patch/build releases within that major/minor version. So if we need to apply a bug fix to an old version, we simply cherry-pick the bugfix commit from master onto the appropriate branch, then tag the new commit with the new version number it gets during deployment.

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.