git - 在 github 上交换 "Latest release"

Question

我有一个 repository on a github .

这是图表:

这是我的 Action 顺序:

1. 进行 5 次提交并推送它们

2. 添加标签 v0.2.0 (git tag -a v0.2.0 -m "release 0.2.0")

3. 推送标签(git push --tags origin master)

4. 通过 github 站点上的 Draft a new release 按钮发布。我选择了 v0.2.0 标签并得到了 https://github.com/n1k1ch/PrototypeGit/releases/tag/v0.2.0

5. 为之前的提交添加一个标签(git tag -a v0.1.0 b217332279 -m "release 0.1.0")

6. 推送标签(git push --tags origin master)

7. 使用v0.1.0 标签通过起草新版本 发布并获得https://github.com/n1k1ch/PrototypeGit/releases/tag/v0.1.0

因此，v0.1.0 标签成为最新版本

问题:

我能否将 v0.1.0 版本与 v0.2.0 版本交换，使 v0.2.0 成为 最新版本?

---

附言googling "github swap release"没有帮助

---

编辑:

感谢@Chris，我做到了。一个小笔记 - 在 Windows 上我使用:

SET GIT_COMMITTER_DATE="2014-04-02 23:00"
git tag -a v0.1.0 b217332279 -m "release 0.1.0"
git push --tags origin master

只是如果有人感兴趣，在此之后我会看到以下内容:

我打开了 v0.1.0 并按下发布版本结果是:

---

我也收到了support@github.com的回复:

This is expected behavior. We're going by the date of your v0.1.0 release, not the date of the last commit. Here's a good blog post about changing the date of an annotated tag: http://sartak.org/2011/01/replace-a-lightweight-git-tag-with-an-annotated-tag.html

Answer 1

我不知道有什么方法可以直接在 GitHub 中执行此操作。 “最新版本”是根据标签上的时间戳确定的，而不是根据其名称的语义确定的。

过去，我通过删除有问题的旧标签解决了我自己个人项目中的这个问题:

git tag -d v0.1.0
git push --delete origin v0.1.0

并用假日期重新创建它:

GIT_COMMITTER_DATE="2013-12-31 00:00" git tag -a v0.1.0.1 b217332279 -m "release 0.1.0.1"
git push --tags origin master

这在 the manpage for git-tag 中有记录:

On Backdating Tags

If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify the date to embed inside of the tag object; such data in the tag object affects, for example, the ordering of tags in the gitweb interface.

To set the date used in future tag objects, set the environment variable GIT_COMMITTER_DATE (see the later discussion of possible values; the most common form is "YYYY-MM-DD HH:MM").

For example:

$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

请注意，同一联机帮助页强烈建议反对重用相同的标签名称:

On Re-tagging

What should you do when you tag a wrong commit and you would want to re-tag?

If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you're done.

But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:

1. The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.

2. The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn't already published the old one.

However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn't just make them overwrite the old one.

If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:

Ok, I messed up, and I pushed out an earlier version tagged as X. I then fixed something, and retagged the fixed tree as X again.

If you got the wrong tag, and want the new one, please delete the old one and fetch the new one by doing:

git tag -d X  
git fetch origin tag X

to get my updated tag.

You can test which tag you have by doing

git rev-parse X

which should return 0123456789abcdef.. if you have the new version.

Sorry for the inconvenience.

是不是有点复杂？ 应该是。自动“修复”它是不可能的。人们需要知道他们的标签可能已被更改。

如果您的项目相对独立并且您可以可靠地联系可能使用该代码的每个人，我只会重复使用相同的标签。

有关删除远程标签的更多详细信息，请查看 this question。