我刚从 Subversion 切换到 Git。Subversion 的集中式架构为它提供了一个有意义的修订号，我用它来构建我们基于 Web 的应用程序的更改日志，以便轻松登录并查看在任何给定服务器上运行的版本。Git 没有友好的内部版本号。相反，我看到它建议您从git statusor的输出中解析某些内容git tags。
我不相信我们会始终为我们的分支机构使用客户友好的名称（有时我们为不希望他们使用我们系统的事实的个人客户命名）。所以我想我可以让构建生成一个 datestamp/timestamp 标记2012-11-21_08-40-23，就像我过去使用 Subversion 修订号的方式一样。当我们构建一个用于部署的war文件时，构建只会生成这个标签并将其添加到Git中，因此任何部署到任何服务器都会生成一个标签。
目前，我们每隔几天部署一次测试，一个月集成几次（突发），每隔几个月进行一次生产。
您可能想查看git-version-gen脚本以生成漂亮的版本号。
它假定您有“vX.Y”形式的标签，并会为您提供“vX.Yz-aaaaaaaa”之类的版本号，其中 z 是提交数，因为标签 vX.Y 和 aaaaaaaaa 是当前 HEAD 的缩短 SHA。
至于标记策略，以这种方式标记发布版本绝对值得。在集成和测试版本上使用它取决于开发的速度。
它也适用于私人开发人员构建，因为标签是从源服务器中提取的。
相反，我看到它建议您从 git status 或 git 标签的输出中解析某些内容。
这是丑陋的建议。真是又丑又蹩脚。git describe规则在这里或多或少，阅读man git describe会比statusor tagor or logor 3-rd-party ready-to-use 脚本有用得多
嗯。像这样对任何修订进行良好命名的技巧（并且您只能标记一些变更集，而不是每个已发布的）
git describe --tags --long --match 'SUBSTRING-OF-CLIENT_TAGFAMILY*'
SVN 中修订号的意义在于能够将已发布的代码与源代码控制中的特定修订相关联。我现在认为标记是不必要的，我的问题的答案实际上是只使用由以下生成的提交哈希：
git log -1 --format=%H
我以前从未回答过我自己的问题。谢谢大家的回答。我给了你们每个人一个 +1 的尝试。如果我的问题措辞不当（回想起来 - 确实如此），我深表歉意。如果有人想向我解释为什么这是错误的以及如何解决它（或做得更好），我很乐意接受他们的答案作为正确答案。
当你从 subversion 切换到 git 时，你会发现有几个概念具有相同的名称，但含义却截然不同。
分支机构是最大的。我知道的大多数使用 git 的商店都在使用分支。事实上，对于每个功能、错误修复、杂务等，都有一个分支。该分支基本上是在代码正在开发、审查、本地测试时临时构建的。然后分支被合并到 master 并被推送到 QA 区域，最后 master 被推送到生产环境。
不过，分支命名是其中一种风格。我有一位同事使用 inits_pt575757_whatever 以便他可以引用跟踪系统 ID，另一位同事使用 pete_1 因为他认为这只是他自己的临时事物，很快就会被合并然后删除。
我倾向于看到标签更多地用于主要版本，但 ymmv
有关整个过程的更多信息，请访问https://stackoverflow.com/a/9204499/631619