Is it a good practice to make a tag in git for every deployment build?
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.
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.Yz-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.
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*'
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.
链接地址: http://www.djcxy.com/p/7548.html