我刚从 Subversion 切换到 Git。 Subversion 的集中式架构为其提供了一个有意义的修订号，我曾经将它构建到我们基于 Web 的应用程序的更改日志中，以便于登录并查看在任何给定服务器上运行的版本。 Git 没有友好的内部版本号。相反，我看到它建议您从 git status 或 git tags 的输出中解析一些内容。
我不相信我们将始终为我们的分支机构使用客户友好的名称（有时我们为不希望公开他们使用我们系统的事实的个人客户命名）。所以我想我可以让构建生成一个日期戳/时间戳标记，如2012-11-21_08-40-23，并像我过去使用 Subversion 修订号一样使用它。构建只会在我们构建用于部署的 war 文件时生成此标记并将其添加到 Git，因此任何部署到任何服务器都会生成一个标记。
目前，我们每隔几天部署一次测试，每月集成几次（突发），每隔几个月进行一次生产。
【问题讨论】：
标签： git svn web-applications deployment build
我看到它建议你从 git status 或 git 标签的输出中解析一些东西。
这是丑陋的建议。真是又丑又蹩脚。 git describe 规则在这里或多或少，阅读 man git describe 将比 status 或 tag 或 log 或 3-rd-party 即用型脚本有用得多
像这样对任何修订进行良好命名的技巧（并且您只能标记 some 变更集，而不是每个发布的）
git describe --tags --long --match 'SUBSTRING-OF-CLIENT_TAGFAMILY*'
【讨论】：
您可能想查看git-version-gen 脚本以生成漂亮的版本号。
假设您有“vX.Y”形式的标签 并会为您提供版本号，例如“vX.Y-z-aaaaaaaa”，其中 z 是提交次数，因为标签 vX.Y 和 aaaaaaaaa 是当前 HEAD 的缩短 SHA。
至于标记策略，以这种方式标记发布版本绝对值得。 在集成和测试版本上使用它取决于开发的速度。
它也适用于私人开发者构建，因为标签是从源服务器中提取的。
【讨论】：
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
【讨论】：