Why does Git have tags?

Question

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?

Answer 1

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)

Answer 2

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.