Is it a good practice to make a tag in git for every deployment build?

Question

I just switched from Subversion to Git. Subversion's centralized architecture gives it a meaningful revision number that I used to build into the change-log for our web-based application to make it easy to log in and see which version is running on any given server. Git doesn't have a friendly build number. Rather I've seen it suggested that you parse something from the output of git status or git tags.

I'm not convinced we will always use customer-friendly names for our branches (sometimes we name them for an individual customer who doesn't want the fact that they use our system publicized). So I'm thinking I could have the build generate a datestamp/timestamp tag like 2012-11-21_08-40-23 and use that the way I used to use the Subversion revision number. The build would only generate this tag and add it to Git when we build a war file for deployment, so any deploy to any server would generate a tag.

Currently we deploy to test every few days, integration a few times a month (in bursts), and production every couple months.

Answer 1

You might want to look at git-version-gen script for generating nice version numbers.

It assumes you have tags of form 'vX.Y' and will give you version numbers like 'vX.Y-z-aaaaaaaa' where z is number of commits since tag vX.Y and aaaaaaaa is shortened SHA of current HEAD.

As for tagging strategy, it definitely is worth tagging release versions this way. Using it on integration and test version depends on how fast development is moving.

It will also work on private developer builds as tags are pulled form origin server.

Answer 2

Rather I've seen it suggested that you parse something from the output of git status or git tags.

It was ugly suggestions. Really ugly and lame. git describe rule here more or less, reading man git describe will be a lot more useful, than status or tag or log or 3-rd-party ready-to-use scripts

Smth. like this do the trick of good naming of any revision (and you can tag only some changeset, not every published)

git describe --tags --long --match 'SUBSTRING-OF-CLIENT_TAGFAMILY*'

Answer 3

The point of the revision number in SVN was to be able to associate the released code with a specific revision in source control. I'm thinking now that tagging is unnecessary and that the answer to my question is actually to just use the commit hash as generated by:

git log -1 --format=%H

I've never answered my own question before. Thank you everyone for your answers. I gave each of you a +1 for trying. I apologize if my question was worded poorly (in retrospect - it was). If someone wants to explain to me why this is wrong and how to fix it (or do it better), I'll gladly accept their answer as the correct one.

Answer 4

Once of the things you'll find when switching from subversion to git is that several concepts have the same name but mean quite different things.

Branches is among the biggest. Most shops I know using git are using branches a lot. In fact for every feature, bug fix, chore, etc, there's a branch. The branch is basically a temporary construction while the code is being developed, reviewed, locally tested. Then the branch gets merged into master and that gets pushed to the QA area(s), then finally the master gets pushed to production.

Branch naming is one of those style things though. One colleague I have uses inits_pt575757_whatever so he can reference the Tracking System ID, the other colleague uses pete_1 as he treats is as just a temporary thing for himself, soon to be merged then deleted.

I tend to see tags used more for major versions but ymmv

More info on the overall process at https://stackoverflow.com/a/9204499/631619