以下几行：
$ git tag -n1
v1.8 Tagged the day before yesterday
v1.9 Tagged yesterday
v2.0 Tagged today
$ git describe
v1.9-500-ga6a8c67
$
任何人都可以解释为什么“git describe”不使用v2.0标签，以及如何解决这个问题？ v2.0标签已被推送，所以我猜我不能删除并重新添加它。
答案 0 :(得分：70)
git describe仅使用带注释的标记。指定--tags选项以使其也使用轻量级标记
确保您已检出正确的提交（git rev-parse HEAD）。使用git tag -a创建带注释的标签。如果您执行git show <tagname>并且只看到提交，则它是一个轻量级标记，如果您看到一个附加标记消息，则它是一个带注释的标记。
答案 1 :(得分：17)
当我们遇到这种情况时，就是两个标签应用于同一次提交的情况。你可以通过运行
找到这种情况# git log --oneline --decorate=short
deba4b4 (tag: v1.1.0.20.0, tag: v1.1.0.19.0) 001 New buildnumber
这里有两个标签，一个用于版本19，另一个用于20.20在19之后被标记，但是用于相同的提交。在这种情况下描述返回
# git describe --tags
v1.1.0.19.0
我不知道为什么会这样做，但这就是它似乎与重复标签一起使用的方式。
另一种可能发生这种情况的情况是，如果您在分支中有一个更“靠近”的标记。 this blog post已解释了这种情况。
答案 2 :(得分：13)
问题是<option value="0" selected>Mustard</option>
在所有分支中显示所有标记，而git tag仅使用当前分支中提供的提交标记。
这是一个例子（我实际来到这里的原因）：
git describe它显示可用的最新代码为 $ git tag | tail -n3
v0.4.0
v0.4.1
v0.4.2
，但这是我v0.4.2的输出：
git describe我正在开发分支机构。当我深入研究日志时，我确实看到当前分支上没有最新的标签：
$ git describe --tags
v0.4.0-2-acd334c
所以在我的情况下，开发人员决定专门为标记版本创建一个新的发布分支，这导致开发分支不再与标签保持同步。
希望通过查看日志帮助并感谢@eis。
答案 3 :(得分：1)
在您的示例中，v1.9最有可能是来自合并提交的标记。
默认情况下，这是预期的git行为，您可以在此处阅读有关它的更多信息： https://git.kernel.org/pub/scm/git/git.git/commit/?id=80dbae03
要在当前分支上查找最新标签时忽略合并标签，可以使用--first-parent选项。
git describe --tags --first-parent --abbrev=0
-第一位父母
在看到合并提交后，仅关注第一个父提交。如果您希望与目标提交历史记录中合并的分支上的标签不匹配，这将很有用。