4

If you can use a tag only once (unique by commit), what do I do with 7 commits in tag "Version 7.3"?
I hate that GIT doesn't make revision numbers (like SVN :)).

I guess a subquestion would be:
What would be a best practice to 'control' version numbers (ex revisions, so I want to save major.minor in every commit and DEFINITELY in every branch (I make >= 1 branch per minor)).

The first question has a factual answer (I think).
The second is more of a best practice probe.

Much appreciated! I have learned much GIT from stackoverflow FTW!

Gilles 'SO- stop being evil'
  • 104,111
  • 38
  • 209
  • 254
Rudie
  • 52,220
  • 42
  • 131
  • 173
  • What do you mean by: "what do I do with 7 commits in tag Version 7.3"? A tag just references a single commit. Are you asking what to do with the seven commits between version 7.2 and 7.3? – kubi Sep 24 '10 at 20:25
  • For what it's worth, having revision numbers would prevent us from keeping commits in order in the timeline. Most people seem to make a branch when they create the new version. There's no reason you can't have 7 commits in a tag (well, technologically at least :P). Checking out the branch will still give you the most recent stable for that release. – Chuck Vose Sep 24 '10 at 20:27
  • @kubi Exactly my point: "one tag references one commit"? That kinda sucks, no? I'd like to tag my commits with a version 'number' (major.minor[.revision]). I guess your comment answers my 1st question and hilites my 2nd: what to do for actual version numbering (GIT versioning a23d4d3...etc isn't readable!) @Chuck Your answer brings hope. Please elaborate! I like "well, technologically at least" - it means it's not set in stone and that's always a good thing in my book. Question handle/reference point: I need easy version numbers in my commits (>= 1 commit per minor & 1 commit = 1 revision) – Rudie Sep 24 '10 at 20:33
  • @Kubi And I guess you're right about what I mean: "what to do with the seven commits between version 7.2 and 7.3" > how do I save that humanly readable? Not tag the 6 revisions in between? – Rudie Sep 24 '10 at 20:34
  • 1
    as I mention in my answer, it is called `git describe`. – VonC Sep 24 '10 at 20:39

2 Answers2

12

I'm not sure what your first question is, but I can answer the second question for you.

Just tag each release. 'v1.0', 'v1.1', 'v2.0'. Tags are completely separate from branches, so how you choose to handle tags doesn't depend on how you choose to handle branches.

For example, if your repo looks like this:

A--B--C--D--E  <- master
   \
    --C'-D'-E' <- test_branch

You can apply a tag to branch E' and safely delete test_branch, without losing the code in E'. For this reason, it's fairly uncommon for people to maintain git branches for historical releases. Tag the release with a version number and feel free to remove any branches you no longer need.

FWIW, I also use this technique to keep my branches to a minimum. If I go down a dead-end development path on a new branch I can tag that branch (just in case) and remove the branch. If I ever need that code again, I can grab it through the tag.

Edit re: your comments.

Exactly my point: "one tag references one commit"? That kinda sucks, no?

I don't think it sucks at all. If you want to keep a reference a point in time, you use a tag, if you want to keep a reference to set of changesets, you use a branch.

@VonC's mention of git-describe is right on. It's what I use to inject version numbers into all my code. Anything released to the public will always get a tag, so git describe returns something like, "v1.0". Internal testing releases will be labeled with something like "v1.0-10-abcd1234", which indicates that I'm 10 commits ahead of the v1.0 tag and gives hash so I can easily access that commit directly.

kubi
  • 48,104
  • 19
  • 94
  • 118
  • What reasons are there to favour tags over branches? Not sure I understand the point of using tags and dropping branches. – aidan Mar 01 '18 at 04:12
  • 2
    @aidan a tag is a static pointer to a single commit, a branch points to a commit that can change over time with ongoing development. In the long run, you mostly want tags, to archive significant points in the codebase. Branches are mostly helpful while developing a feature and for other housekeeping, but should be kept to a minimum in the shared repo. – Yawar Aug 02 '18 at 23:00
  • "one tag references one commit" is disappointing if I want to tag multiple commits with the same concept. e.g. "needs-attention" – Don Hatch Sep 26 '20 at 18:55
4

Tags are mainly reserved for application versioning number policy, not internal and technical number (even though, as kubi rightly points out in the comments, you can use them for whatever purpose).
Annotated tags in particular are fit for publication ("push").

There are some ways to simulate a technical revision number in Git, but remember that its distributed aspect will prevent the use of a simple "revision counter".

More generally, git describe is the usual way to reference a commit with some meaningful information in it.
See also "How to programmatically determine whether the Git checkout is a tag and if so, what is the tag name".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I disagree with the first comment. You can use tags for whatever you want. Otherwise, git-describe is a great way to track commits in a relatively user-friendly way. – kubi Sep 24 '10 at 20:57