在github上交换"最新版本"

我在github上有一个存储库.

这是图表:

这是我的动作序列:

进行5次提交并推送它们

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

推标签(git push --tags origin master)

通过github网站上的草稿新版本按钮发布.我选择了v0.2.0标签并获得了https://github.com/n1k1ch/PrototypeGit/releases/tag/v0.2.0

将标记添加到上一个commit(git tag -a v0.1.0 b217332279 -m "release 0.1.0")

推标签(git push --tags origin master)

通过草案发布一个带有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成为最新版本吗？

PS 谷歌搜索"github交换发布"没有帮助

感谢@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的答复:

这是预期的行为.我们将在v0.1.0发布日期之前,而不是上次提交的日期.这是一篇关于更改带注释标签日期的好文章:http: //sartak.org/2011/01/replace-a-lightweight-git-tag-with-an-annotated-tag.html

Chris.. 20

我不知道有任何方法可以直接在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

这在以下联机帮助页中有记录git-tag:

关于回溯标签

如果您从另一个VCS导入了一些更改,并且想为工作的主要版本添加标记,那么能够指定嵌入标记对象内部的日期是很有用的.例如,标签对象中的这种数据会影响gitweb界面中标签的排序.

要设置将来标记对象中使用的日期,请设置环境变量GIT_COMMITTER_DATE(请参阅后面对可能值的讨论;最常见的形式是"YYYY-MM-DD HH:MM").

例如:

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

请注意,同一手册页强烈建议不要重复使用相同的标记名称:

关于重新标记

当您标记错误的提交并且您想要重新标记时,您应该怎么做？

如果你从未推过任何东西,只需重新标记即可.使用"-f"替换旧的.而且你已经完成了.

但是如果你把事情搞砸了(或者其他人可以直接读取你的存储库),那么其他人就已经看到了旧的标签了.在这种情况下,您可以执行以下两项操作之一:

理智的事情.只是承认你搞砸了,并使用不同的名字.其他人已经看过一个标签名称,如果你保持相同的名称,你可能会遇到两个人都有"版本X"的情况,但他们实际上有不同的"X".所以只需称它为"X.1"并完成它.

疯狂的事情.你真的想把新版本称为"X",即使其他人已经看过旧版本.所以只需使用git tag -f again,就好像你还没有发布旧版本一样.

但是,Git不会(也不应该)更改用户背后的标签.因此,如果有人已经获得了旧标签,那么git pull在树上做一个不应该只是让它们覆盖旧标签.

如果有人从你那里得到了一个发布标签,你就不能通过更新自己的标签来改变标签.这是一个很大的安全问题,因为人们必须能够信任他们的标签名称.如果你真的想做疯狂的事情,你需要了解它,告诉别人你搞砸了.你可以通过发布一个非常公开的声明来做到这一点:

好吧,我搞砸了,我推出了一个标记为X的早期版本.然后我修复了一些东西,并将固定的树再次重新标记为X.

如果你得到了错误的标签,并想要新标签,请删除旧标签并通过执行以下操作获取新标签:

git tag -d X  
git fetch origin tag X

获取我更新的标签.

您可以通过测试来测试您拥有的标签

git rev-parse X

哪个应该返回0123456789abcdef ..如果您有新版本.

抱歉给你带来不便.

这看起来有点复杂吗？它应该是.没有办法自动"修复"它是正确的.人们需要知道他们的标签可能已被更改.

如果您的项目相对孤立,我只会重复使用相同的标记,并且您可以可靠地联系可能正在使用该代码的每个人.

有关删除远程标记的更多详细信息,请查看此问题.

我不知道有任何方法可以直接在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

这在以下联机帮助页中有记录git-tag:

关于回溯标签

如果您从另一个VCS导入了一些更改,并且想为工作的主要版本添加标记,那么能够指定嵌入标记对象内部的日期是很有用的.例如,标签对象中的这种数据会影响gitweb界面中标签的排序.

要设置将来标记对象中使用的日期,请设置环境变量GIT_COMMITTER_DATE(请参阅后面对可能值的讨论;最常见的形式是"YYYY-MM-DD HH:MM").

例如:

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

请注意,同一手册页强烈建议不要重复使用相同的标记名称:

关于重新标记

当您标记错误的提交并且您想要重新标记时,您应该怎么做？

如果你从未推过任何东西,只需重新标记即可.使用"-f"替换旧的.而且你已经完成了.

但是如果你把事情搞砸了(或者其他人可以直接读取你的存储库),那么其他人就已经看到了旧的标签了.在这种情况下,您可以执行以下两项操作之一:

理智的事情.只是承认你搞砸了,并使用不同的名字.其他人已经看过一个标签名称,如果你保持相同的名称,你可能会遇到两个人都有"版本X"的情况,但他们实际上有不同的"X".所以只需称它为"X.1"并完成它.

疯狂的事情.你真的想把新版本称为"X",即使其他人已经看过旧版本.所以只需使用git tag -f again,就好像你还没有发布旧版本一样.

但是,Git不会(也不应该)更改用户背后的标签.因此,如果有人已经获得了旧标签,那么git pull在树上做一个不应该只是让它们覆盖旧标签.

如果有人从你那里得到了一个发布标签,你就不能通过更新自己的标签来改变标签.这是一个很大的安全问题,因为人们必须能够信任他们的标签名称.如果你真的想做疯狂的事情,你需要了解它,告诉别人你搞砸了.你可以通过发布一个非常公开的声明来做到这一点:

好吧,我搞砸了,我推出了一个标记为X的早期版本.然后我修复了一些东西,并将固定的树再次重新标记为X.

如果你得到了错误的标签,并想要新标签,请删除旧标签并通过执行以下操作获取新标签:

git tag -d X  
git fetch origin tag X

获取我更新的标签.

您可以通过测试来测试您拥有的标签

git rev-parse X

哪个应该返回0123456789abcdef ..如果您有新版本.

抱歉给你带来不便.

这看起来有点复杂吗？它应该是.没有办法自动"修复"它是正确的.人们需要知道他们的标签可能已被更改.

如果您的项目相对孤立,我只会重复使用相同的标记,并且您可以可靠地联系可能正在使用该代码的每个人.

有关删除远程标记的更多详细信息,请查看此问题.