我的存储库只有一个分支（master）。我是我的回购的唯一贡献者。

我最近tag在本地添加了一个，并将其推送到GitHub。在完成了我的最后一次提交之后，但是现在我意识到我应该再进行一次更改/提交。

所以我有：

commit 124
commit 125
commit 126 <-- tag v1.0
commit 127

并且我想将v1.0标签移动到下一个提交，即127本地和GitHub中。

我怎样才能做到这一点？

您是否去过会员不都使用同一版本的“一周之书”的读书俱乐部？这是一场噩梦，对吧？移动标签实际上会使您处于相同的情况。

如果您将存储库视为一本记录项目进展的书，则可以将标签视为章标题。

共享标签后将标签移至其他提交就像告诉所有读书俱乐部的好友

你们知道吗，伙计们？到目前为止，我们大家一直在使用的这本书的版本已经过时了，因为我只是命令第8章现在开始，而不是在126页上，而是在128页上。

不好。移动标签是重写历史记录的一种形式，您不应该重写已共享的历史记录。这是惹恼您的合作者的最可靠方法。另外，你写

我是我的仓库的唯一贡献者[...]

目前可能是正确的，但是如果您之外的其他人可以访问GitHub存储库（例如，它是公共的），那么其中一些人可能已经分叉或克隆了它（尽管有找到方法），然后您运行重写历史记录可能会惹恼他们。

如果您100％确定无论如何都要移动该标签，Git确实允许您执行此操作。在这里，您可以使用

git tag --force v1.0 <ID-of-commit-127>

然后您必须使用

git push --force --tags

但是再次，请三思而后行...

附录（2018/09/26）

我觉得有必要重新审视我的答案...

多年以来，有人在我的禁令评论中反对不要移动已经发布的标签。当然，这条建议是上下文相关的，而不是通用的。我毫不怀疑存在移动已发布标签的良好案例。但是，我坚信，作为一般规则，对发布的标签进行移动的决定应刻意且极其谨慎。

我想到了一个最近的例子。Go 1.11添加了对模块系统的实验性支持，该模块系统严重依赖于Git标签进行版本控制。在已发布的Go模块中移动标签（例如，在GitHub上）将带来灾难性的后果。

这样做会破坏您（模块作者）和用户（依赖于模块的用户）之间建立的契约，因为您将否定Go的模块系统打算提供的保证：

模块记录精确的依赖要求并创建可复制的构建。

这是让人们生气的一种肯定方法。

这个例子可能足以说服您，至少在某些情况下，您不应该无意间移动已发布的标签。我休息一下

通常不建议移动标签，因为由于Git的高度分布性质，它可能会引起问题。考虑：

• 您v1.0在提交时推送标签abcd123
• 您的好友，称他为弗雷德（Fred），
• 弗雷德现在v1.0在abcd123
• 您移动标签v1.0以提交cccc222并推送
• 可能发生以下情况：
  • Fred获取了，但是v1.0服务器上的标签与他的本地v1.0标签不匹配，因此即使他没有做任何引起冲突的操作，Fred也必须手动解决此冲突
  • 弗雷德（Fred）推动了--tags添加some-tag他创建的新标签的选项；此推送被服务器拒绝，因为他的本地v1.0标签和服务器的v1.0标签不一致

如果有两个以上的开发人员，这将变得更加复杂。如果甚至没有一个人采取步骤更新他或她的本地标签，你也会遇到麻烦。

如果您仍然确定要移动标签（也许这是一个开发人员项目，或者您确定没有人拿到标签，或者您准备与所有其他开发人员进行通信并确保他们会更新其本地标签），您可以执行以下操作：

git tag -a -f v1.0 <new-commit-hash>
git push --tags --force

应鼓励其他开发人员删除其标签的本地副本并获取新的标签：

git tag -d v1.0
git fetch --tags

您也可以删除标签，然后重新创建，这不需要重写历史记录。
（没有push --force）

删除本地和远程

git tag -d <tag_name>
git push origin :refs/tags/<tag_name>

重新建立

git tag <tag_name>
git push --tags