在什么情况下我应该在 git tag 命令中添加 `-a` 标志？
我知道两种类型的命令之间的技术差异（不使用 -a 标志的使用会创建一个轻量级标签，本质上是一个永远不会移动的分支，而使用 -a 标志时会创建一个轻量级标签，该标签本质上是一个永远不会移动的分支code> 在 Git 的对象数据库中创建一个完整的对象，其中包括提交者的姓名、电子邮件等）。
问题是：我应该在我的项目中使用哪一个（例如，在 Github 上指示发布版本）？如果其中一种比另一种更受欢迎，为什么还存在另一种选择？每个版本的用例是什么？
I am aware of the technical differences between the two types of commands (usage without the -a flag creates a lightweight tag which is essentially a branch that never moves, while usage with -a creates a full object in Git's object database which includes the committer's name, email, etc.).
The question is: which one should I use in my projects (to indicate release versions on Github, for example)? And if one is hugely preferred over another, why does the other option exist? What are the use cases for each version?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我想说，对于已发表的作品，您应该始终使用带注释的标签。这些额外的信息永远不会伤害你。
在我看来，轻量级标签更适合当你懒惰的时候。也许是一个临时标签（只要确保您不会意外推送它；实际上您可以只使用分支），或者可能是一个个人存储库，其中额外信息没有多大用处。我的猜测是，很多较小的项目也这样做；他们只是并不真正关心这些信息。可能只有一个集成商，没有人关心验证签名标签，它们只是发布版本的简单标记。 （我仍然认为你应该更喜欢带注释的标签，以防万一！）
另一种思考方式：轻量级标签有点像写一个非常糟糕的提交消息。你确实不应该这样做，但有时人们会这样做，通常是在没有人观看的情况下。
I'd say that with published work, you should just always use annotated tags. That extra information is never going to harm you.
Lightweight tags strike me as being more for when you're being lazy. Maybe a temporary tag (just make sure you don't accidentally push it; really you could just use a branch), or maybe a personal repo where there's not much use for the extra information. My guess is that a lot of smaller projects do this too; they're just not really concerned with the information. Probably there's only one integrator, no one's concerned with verifying signed tags, and they're just simple markers of release versions. (I still think you should prefer annotated tags, just in case!)
Another way of thinking of it: lightweight tags are kind of like writing a really bad commit message. You really shouldn't do it, but sometimes people do, usually when no one's watching.
man git-tag 说：
某些行为确实以这种建议有用的方式区分它们，例如：
git describe仅不含命令行选项看到带注释的标签另请参阅：
man git-tag says:
And certain behaviors do differentiate between them in ways that this recommendation is useful e.g.:
git describewithout command line options only sees annotated tagsSee also:
如果您想推送/获取它们，那么您应该使用带注释的标签。
If you want to to push/fetch them, then you should use annotated tags.
最常见的风格是使用带注释的标签作为永久标签，即您希望推送并且希望其他人查看的内容。然后，轻量级标签用于临时标签，即您不会推送且不希望其他人看到的东西。
The most common style is to use annotated tags for permanent tags, things which you expect to push and you expect other people to look at. Lightweight tags are then used for temporary tags, things which you will not push and which you do not want other people to see.
有几个考虑因素：
功能
带注释的标签可让您创建消息并对其进行签名。它还给出
有关标记器的元数据。你需要那个吗？
有时我只是想暂时标记一个提交，比如“before big
回归”或“大重写之前”。我不
需要任何标签消息，事实上，被提示会
分散注意力。
但对于发布标签，您可能需要编写标签消息。也许
也签名。
一流标签
使用轻量级标签时，您始终需要检查是否
不管 Git 手册页真正意味着“标签”，如“任何标签”或具体的
“带注释的标签”，即我所说的“一流”标签。
在我的工作中，我们并不真正关心我们是否
发布标签是轻量级的或带注释的。直到我们注意到
git-describe(1) 的表现并不像我们预期的那样，因为我们有一个混合
轻量级和带注释的标签（此命令仅查看带注释的
默认标签）。
所以我们开始使用带注释的标签。不是因为第一个
考虑（功能），因为：
v5.6.7的标签消息可能只是......v5.6.7但是使用带注释的标签会更方便，因为
那么我们使用“发布标签”，就 git(1) 套件而言
担心的。
There are a couple of considerations:
Capabilities
An annotated tag lets you create a message and sign it. It also gives
you metadata about the tagger. Do you need that?
Sometimes I just want to mark a commit temporarily, like “before big
regression” or “before big rewrite”. I don’t
need any tag message for that, and in fact being prompted about it would
be distracting.
But for a release tag you might want to write a tag message. And maybe
also sign it.
First-class tag
With a lightweight tag you’re always going to have to check whether
whatever Git manpage really meant “tag” as in “any tag” or specifically
“annotated tag”, i.e. what I’m calling a “first-class” tag.
At my job we didn’t really care one way or the other about whether our
release tags were lightweight or annotated. Right up until we noticed
that git-describe(1) didn’t behave like we expected, since we had a mix
of lightweight and annotated tags (this command only looks at annotated
tags by default).
So we started using annotated tags. Not because of the first
consideration (capabilities) since:
v5.6.7might just be…v5.6.7But using annotated tags turned out to be more convenient just because
then we are using a “release tag”, as far as the git(1) suite is
concerned.