git 将标记向前移动一次提交

Move tag one commit ahead

提问by Gabriel

I have a repository with only one branch (master). I'm the only contributor to my repo.

我有一个只有一个分支 ( master)的存储库。我是我的 repo 的唯一贡献者。

I've recently added a tag, both locally and pushed to GitHub. After making what I though was the last necessary commit, but now I realize I should have made one more change/commit.

我最近tag在本地添加了一个，并推送到 GitHub。在做出我认为是最后一次必要的提交之后，但现在我意识到我应该再做一次更改/提交。

So what I have is:

所以我所拥有的是：

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

and I want to move the v1.0tag to the next commit, ie: 127, both locally and in GitHub.

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

How can I do that?

我怎样才能做到这一点？

回答by jub0bs

Have you ever been to a book club where members do not all use the same edition of the "book of the week"? It's a nightmare, right? Moving a tag would essentially put you in the same situation.

你有没有去过一个读书俱乐部，那里的成员并不都使用相同版本的“本周之书”？这是一场噩梦，对吧？移动标签基本上会使您处于相同的情况。

If you think of your repository as a book that chronicles progress in your project, you can think of a tag as a chapter heading.

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

Moving a tag to a different commit after sharing it is like telling all your book-club buddies

分享后将标签移动到不同的提交就像告诉你所有的读书俱乐部伙伴

You know what, guys? The edition of the book we've all been using so far is now obsolete, because I have solely decreed that chapter 8 shall now start, not on page 126, but on page 128.

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

Not good. Moving a tag is a form of history rewriting, and you shouldn't rewrite history that has been shared. It's the surest way to piss your collaborators off. Besides, you write

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

I'm the only contributor to my repo [...]

我是我的回购的唯一贡献者 [...]

That may be true for now, but if other people than you have access to your GitHub repository (e.g. if it's public), some of them may already have forked or cloned it (although there is a wayto find out), and you run the risk of pissing them off if you rewrite history.

现在可能是这样，但是如果除了您之外的其他人可以访问您的 GitHub 存储库（例如，如果它是公开的），那么他们中的一些人可能已经分叉或克隆了它（尽管有一种方法可以找出），然后您运行如果你改写历史，就有可能惹恼他们。

---

---

If you're 100% sure that you want to move that tag anyway, Git does allow you to do it. Here, you could use

如果您 100% 确定无论如何要移动该标签，Git 确实允许您这样做。在这里，你可以使用

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

and then you would have to force push that tag, using

然后你将不得不强制推送该标签，使用

git push --force --tags

But again, think twicebefore going ahead...

但同样，在继续之前请三思......

Addendum (2018/09/26)

附录 (2018/09/26)

I feel the need to revisit my answer...

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

Over the years, some people have objected in the comments to my injunction not to move an already published tag. Of course, this piece of advice is contextual rather than universal; I don't doubt that good cases for moving a published tag exist. However, I stand firm in the belief that, as a general rule, the decision to move a published tag should be made deliberately and with extreme care.

多年来，有些人在评论中反对我禁止移动已发布标签的禁令。当然，这条建议是基于上下文的，而不是普遍的；我不怀疑存在移动已发布标签的好案例。但是，我坚信，作为一般规则，移动已发布标签的决定应慎重并谨慎做出。

One recent example comes to mind. Go 1.11 added experimental support for a module systemthat relies heavily on Git tags for versioning. Moving a tag in a Go module that has been published (on GitHub, say) would have disastrous consequences.

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

By doing so, you would break the contract established between you (the module author) and your users (those who depend on your module), because you would negate the guarantees that Go's module system intends to provide:

这样做，你会破坏你（模块作者）和你的用户（那些依赖你的模块的人）之间建立的合同，因为你会否定 Go 的模块系统打算提供的保证：

Modules record precise dependency requirements and create reproducible builds.

模块记录精确的依赖需求并创建可重现的构建。

That's one sure way to piss people off.

这是激怒人们的一种可靠方法。

This example may be enough to convince you that, at least in some cases, you shouldn't mindlessly move published tags. I rest my case.

这个例子可能足以让您相信，至少在某些情况下，您不应该盲目地移动已发布的标签。我休息一下。

回答by Chris

Moving tags is generally discouraged since it can cause problems due to Git's highly distributed nature. Consider:

通常不鼓励移动标签，因为 Git 的高度分布式特性可能会导致问题。考虑：

• You push tag v1.0on commit abcd123
• Your buddy, call him Fred, fetches
• Fred now has a local v1.0tag on abcd123
• You move tag v1.0to commit cccc222and push
• The following things can happen:
  • Fred fetches, but the v1.0tag on the server doesn't match his local v1.0tag, so Fred has to manually fix this conflict, even though he didn't do anything to cause it
  • Fred pushes with the --tagsoption to add a new tag some-tagthat he created; this push is rejected by the server because his local v1.0tag and the server's v1.0tag disagree

• 你v1.0在提交时推送标签abcd123
• 你的伙计，叫他弗雷德，取
• Fred 现在有一个本地v1.0标签abcd123
• 您将标签移动v1.0到提交cccc222和推送
• 可能会发生以下事情：
  • Fred 获取，但v1.0服务器上的标签与他的本地v1.0标签不匹配，因此 Fred 必须手动修复此冲突，即使他没有采取任何措施导致冲突
  • Fred--tags选择添加some-tag他创建的新标签；这个推送被服务器拒绝，因为他的本地v1.0标签和服务器的v1.0标签不一致

With more than two developers this gets much more complicated; if even one person doesn't take the step to update his or her local tag you can get trouble down the line.

如果有两个以上的开发人员，这会变得更加复杂；即使一个人不采取措施更新他或她的本地标签，您也可能会遇到麻烦。

If you're still sure that you want to move the tag (perhaps this is a one developer project, or you're otherwise sure that nobody has fetched the tag, or you're prepared to communicate with all other developers and make sure that they update their local tags) you can do something like this:

如果您仍然确定要移动标签（也许这是一个开发人员项目，或者您确定没有人获取标签，或者您准备与所有其他开发人员沟通并确保他们更新他们的本地标签）你可以做这样的事情：

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

Other developers should be encouraged to delete their local copy of the tag and fetch the new one:

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

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

回答by Jonas Marty

You could also delete the tag and then recreate it, this does not require a rewrite of the history.
(No push --force)

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

Delete local and remote

删除本地和远程

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

Recreate

重新创建

git tag <tag_name>
git push --tags