我去年从Subversion转到Git作为我的日常VCS，我仍在努力把握“Git-think”的细节。
最近一直困扰我的是“轻量级”与注释与签名标签相比。对于所有实际用途来说，注释标签优于轻量级标签似乎是普遍接受的，但我发现为什么会出现这种情况的解释似乎总是归结为"because best practices"或"because they're different"。不幸的是，如果不知道为什么它是最佳实践，或者这些差异与我的Git用法相关，那些是非常不满意的论据。
当我第一次切换到Git时，轻薄的标签似乎是自切片面包以来最好的东西;我可以指出一个提交并说“那是1.0”。我很难掌握标签如何比这更好，但我当然不能相信世界的Git专家更喜欢任意注释标签！那么什么是喧哗？
（奖励积分：为什么我需要签署一个标签？）
修改
我一直successfully convinced注释标签是好事 - 知道谁标记，何时重要！作为后续行动，有关良好标签注释的任何建议吗？两个git tag -am "tagging 1.0" 1.0并试图总结提交日志，因为上一个标记感觉就像丢失策略一样。
答案 0 :(得分：249)
带标注标签的一大优点是，您知道是谁创建了它。就像提交一样，有时很高兴知道是谁做的。如果您是开发人员，并且您发现v1.7.4已被标记（已宣布准备好）并且您不确定，那么您与谁交谈？名称在注释标签中的人！ （如果你生活在一个不信任的世界里，这也让人们不会躲过他们不应该做的标记。）如果你是一个消费者，那个名字就是权威的印记：那是Junio Hamano说的这个版本的git特此释放。
其他元数据也可能有用 - 有时很高兴知道该版本何时发布，而不仅仅是在最终提交时。有时候这条消息甚至可能有用。也许它有助于解释特定标签的用途。也许候选版本的标记包含一些状态/待办事项列表。
签名标签非常类似于签署其他任何东西 - 它为偏执狂提供了更多级别的安全性。我们大多数人都不会使用它，但如果您真的想在将该软件放到计算机上之前验证所有内容，那么您可能需要它。
编辑：
至于在标签注释中写什么，你是对的 - 说起来并不总是有用。对于版本号标签，它隐含地理解它标记该版本，如果您对其他地方的更改日志感到满意，则无需在那里放置。在这种情况下，它确实是最重要的标记器和日期。我能想到的另一件事就是从测试套件中获得某种批准。看看git.git的标签：他们都只是说“Git 1.7.3 rc1”;我们真正关心的是Junio Hamano的名字。
但是，对于不那么明显命名的标签，消息可能变得更加重要。我可以设想为单个用户/客户端标记特定的特殊用途版本，一些重要的非版本里程碑，或者（如上所述）具有额外信息的候选版本。这条消息更有用。
答案 1 :(得分：59)
我对该主题的个人观点略有不同：
答案 2 :(得分：25)
默认情况下，Git仅将带注释的标签作为git describe等命令的基线。将带注释的标签视为对自己和他人具有持久意义的路标，而轻量级标签更像是后来自己找到的书签。因此，带注释的标签值得用作参考，而轻量级标签则不应该。
签署标签是签名者身份的保证。例如，它允许用户验证他们选择的Linux内核代码与Linus Torvalds实际发布的代码相同。签名也可以是一个断言，即签名者在该提交时担保软件的质量和完整性。
答案 3 :(得分：9)
签署标签是断言发布的真实性的简单方法。
这在DVCS中特别有用，因为任何人都可以克隆存储库并修改历史记录（例如，通过git-filter-branch）。如果标签已签名，则签名将无法在git-filter-branch操作中继续存在，因此如果您的策略是每个版本都由提交者标记并签名，则可以在存储库中检测虚假发布标记。
如果不是签名，我也不会在注释标签中看到太多意义。
答案 4 :(得分：7)
推送带注释的标签，保持轻量级本地
某些Git行为会以这种建议有用的方式区分它们，例如：
带注释的标记可以包含与它们指向的提交不同的消息，创建者和日期。因此，您可以使用它们来描述发布，而无需进行发布提交。
轻量级标签不具备这些额外信息，并且不需要它，因为您只是自己使用它来开发。
git describe只能看到带注释的标签 man git-tag说：
带注释的标签用于发布，而轻量级标签用于私有或临时对象标签。
内部差异
轻量级和带注释的标签都是.git/refs/tags下包含SHA-1的文件
对于轻量级标签，SHA-1直接指向提交：
git tag light
cat .git/refs/tags/light
打印与HEAD的SHA-1相同。
所以难怪他们不能包含任何其他元数据。
带注释的标签指向对象数据库中的标签对象。
git tag -as -m msg annot
cat .git/refs/tags/annot
包含带注释的标记对象的SHA：
c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
然后我们可以通过以下方式获取其内容：
git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
示例输出：
object 4284c41353e51a07e4ed4192ad2e9eaada9c059f
type commit
tag annot
tagger Ciro Santilli <your@mail.com> 1411478848 +0200
msg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
<YOUR PGP SIGNATURE>
-----END PGP SIGNAT
这就是它包含额外元数据的方式。正如我们从输出中看到的，元数据字段是：
格式的更详细分析见：What is the format of a git tag object and how to calculate its SHA?
<强>奖金
确定标签是否已注释：
git cat-file -t tag
为轻量级commit输出tag以进行注释。
仅列出轻量级代码：How can I list all lightweight tags?
答案 5 :(得分：6)
我发现了一个很好用的轻量级标签 - 在GitHub上回顾展创建一个版本。
我们确实发布了我们的软件并且我们已经进行了必要的提交，我们只是没有费心去维护“发布”。关于GitHub的部分。当我们给予一点关注时，我们已经意识到我们也想要添加一些以前的版本，并为它们提供正确的旧发布日期。
如果我们只是在旧提交上创建带注释的标记，GitHub将从标记对象中获取发布的日期。相反，当我们为这个旧提交创建一个轻量级标记时，该版本开始显示正确的（旧）日期。 Source @ GitHub help, 'About releases'
似乎也可以为带注释的提交指定所需的日期，但对我来说这看起来并不简单： https://www.kernel.org/pub/software/scm/git/docs/git-tag.html#_on_backdating_tags
答案 6 :(得分：1)
在我的办公室，我们会将发布网页地址放在标签正文中。发布网页详细介绍了自上一版本以来的所有不同新功能和修复。管理层不会在git仓库中查找发现了哪些变化，并且很清楚地列出该版本中的内容。
答案 7 :(得分：0)
带注释的标签将额外的元数据（如作者姓名，发行说明，标签消息和日期）存储为Git数据库中的完整对象。所有这些数据对于项目的公开发布非常重要。
git tag -a v1.0.0
轻量级标签是将标签添加到git存储库的最简单方法，因为它们只存储它们引用的提交的哈希值。他们可以表现得像＃34;书签＆＃34;因此，它们非常适合私人使用。
git tag v1.0.0
您可以对旧标签进行排序，列表，删除，显示和编辑。所有这些功能将帮助您识别代码的特定发行版本。我发现this article可以帮助您更好地了解标记可以做什么。
答案 8 :(得分：0)
对我来说，重要的区别是轻量级标签没有时间戳。假设您添加了几个轻量级标签：
git tag v1
git tag v2
git tag v3
，然后，也许以后，您想要获取最后添加的轻量标签。没有办法做到这一点。 “ git describe”和“ git tag”都不会按时间顺序为您提供最后的轻量级标签。 “ git tag -l”可以返回它们全部或按lex顺序对其进行排序，但不能按日期/时间排序。 “ git describe --tags”将返回“ v1”，这绝对不是最后添加的标签。
另一方面，如果您添加带注释的标签：
git tag v1 -m v1
git tag v2 -m v1
git tag v3 -m v1
您始终可以获得每个标签的时间戳，“ git describe”将确保返回“ v3”，这实际上是最后添加的标签。