在
网站开发项目中，由于 正确使用 Git 标签，存在的第一个 Git 管理的项目v4.11-rc7-87-g28cf22d0ba28相当于 28cf22d0ba28. 这是由于注解的存在v4.11-rc7。更好的字符串是git describe. 当传递前者时，接受后者的任何命令的行为都相同。当 git 出现时[anystring]-g[hash]，它会丢弃[anystring]-g 前缀，并将[hash]part 视为所需的提交来解决。
Git 标签让我们可以使用派生它的软件版本来美化任何 Git 哈希。然而，在许多项目中，Git 标签在最好的情况下通常没有充分发挥其潜力，而在最坏的情况下，它们被滥用了。在这篇文章中，我提供了一些建议列表，以帮助在任何项目中实现从 Git 标记中获得的精确性。
一个常见的陷阱是让任何开发人员推送 Git 标签。以下情况发生在不止一家公司中：有人推了一个test标签。其他人test在项目的根目录中创建了子目录。现在，git log test是一个不知道该做什么的模棱两可的命令。它应该显示从 指向的提交开始的提交test，还是来自HEAD修改该test目录的提交？或者开发商有一个本地test分支？头痛。
如果可能，将 Git 服务器配置为仅接受来自发布管理器的标签推送。标签是独一无二的，并且永远存在于 repo 中。选择不会与您的分支名称约定产生歧义的良好标签名称。
一个不错的约定如下：要标记版本，请以v. 这样，shell 完成在尝试完成时可以很好地工作v。如果您放弃v 并立即使用版本号 .eg 1.，shell 完成将难以显示以 开头的标记1和所有 git 哈希以 开头的提交之间的完成1。
默认情况下git tag创建轻量级标签（非注释标签）。请传递-a开关以创建带注释的标签。这样，创建标签的元数据就像提交一样被注册。此外，git describe开箱--tags即用，不需要强制它考虑轻量级标签所需的标志。
Git 标签只是 Git 的补充信息，它们不是源本身。使用 Git 标记和源代码树文件来告知代码的版本。这通常是您选择的生态系统的包管理器清单中的版本字符串。但是如何正确地做到这一点？即应该标记哪些提交？这将我们带到下一个建议 。
