首先，在git reflog中移动标记首先是一个本地操作（可以跟踪90天）。
只要标记未被推，您可以根据需要多次移动它。
一旦被推，它应该被认为是不可变的。
这意味着如果“它是[通常]一个错误的或过早的标签，旨在成为指向特定提交的指针，但需要被移动”，那么，如果它被推送，您需要创建一个新标签。
例如，对于错误应用的1。1.0标签：创建一个1。1.1标签而不是初始的1。1.0.
发布1。1.0_deprecated当前由% 1引用的提交。1.0更好地传达了1.1.0标签不应被考虑。

如何在git中查看标签的历史记录？
你不能，它不存在。
轻量级标签和分支是指向提交的标签。每一个都是一个single file on disk或packfile中的一行，带有一个名称和它所指向的提交ID。他们没有历史。移动标记或更新分支时，文件或行将被覆盖。
带注解的标记的工作方式相同，但它们具有标记对象的名称和ID。标记对象包含标记名称、注解和它所指向的提交。git tag -a -f创建一个新的标记对象，并将文件/行更改为指向新标记对象。没有历史。
下面是一个无法到达的标记对象内部的内容。

$ git fsck --unreachable | grep tag
Checking object directories: 100% (256/256), done.
Checking objects: 100% (3/3), done.
unreachable tag f25f9e059dc07f741aae47ee422f675b9bdd0f5f

$ openssl zlib -d < .git/objects/f2/5f9e059dc07f741aae47ee422f675b9bdd0f5f
 
tag 153object 91e645c1a8a2ff1edc788066ef02f349f959da20
type commit
tag annotated
tagger Michael G. Schwern <schwern@pobox.com> 1620501711 -0700

test annotated

它指向commit 91 e645 c。今天我贴了标签。注解为“测试注解”。
正如您所注意到的，在移动标记的存储库上，假设它们尚未被垃圾收集，则可以将其转移到find unreferenced tag objects。git fsck --unreachable | grep tag这只是错误后恢复的紧急操作，不应成为正常程序的一部分。备份是更好的选择。
在真实的世界中，开发人员在正式发布之前移动标签的情况经常发生。
那他们就用错标签了。标签的唯一目的是“不”移动。移动的标记是分支。使用分支代替。
例如，您可能有一个release标记，每次发布新版本时都会移动它。将其替换为一个名为release的分支。它们在功能上是等价的，但是发布 * 分支 * 应该移动。
发布分支仍然没有历史记录。如果你想要一个发布历史，那就是标签的作用。标记每个版本，例如v1.0.0、v1.0.1、v1.1.0等等。如果标签是错误的并且已经被推送 * 不要改变标签 *，声明一个新的版本。

如果你想要一个所有标签更改的审计日志，你可以告诉git保留一个：
git config --global core.logallrefupdates always
之后，git将开始跟踪reflog中所有标签的所有更改。要找出标签被移动或删除的原因，以及它之前指向的位置，你可以简单地查询refog：
git reflog mytagname
请注意，至少在默认情况下，这个历史不会永远保留，因为它受到通常的reflog过期规则的影响。您可以通过更改以下选项来防止这种情况：

• gc.refs/tags.reflogExpire
• gc.refs/tags.reflogExpireUnreachable

所以，与其他答案相反，你想要的绝对是可能的。（有一些限制，例如reflog是每个克隆的本地，这意味着您不会有一致的，共享的标记历史。）
我也认为，关于你是否应该这样做的哲学辩论是不必要的。虽然git标签肯定不是为了移动而设计的，但我也遇到过这样的情况，我需要这样做，并且为每个标签设置一个用于调试目的的审计日志是有意义的，即使你从来没有打算移动它们。