如何将新提交纳入GitHub已发布的旧版本中？

嘿，这个场景太常见了——发完Release才发现漏了个小修改，别急，完全能搞定，而且有更稳妥的办法，不用折腾提交日期那种容易出问题的操作。

首选方案：直接更新现有Release（最推荐） #

GitHub本身就支持更新已发布的Release，把新提交关联进去，步骤超简单：

• 打开你的仓库，进入「Releases」页面找到要调整的版本
• 点版本详情页右上角的「Edit release」按钮
• 在「Target」下拉框里，选包含新提交的master分支（或者直接输入那个新提交的哈希值）
• 要是需要更新版本说明也可以在这里改，最后点「Update release」就完事了

操作完之后，这个Release就会指向最新的提交，页面上那句“此版本发布后master分支有1次提交”的提示自然就没了，而且所有下载链接都会自动同步到新的代码包，版本号也不用变，完美。

备选方案：删除旧Release后重新发布（不推荐，谨慎用） #

如果你想彻底替换掉原来的Release，也能这么做，但要注意副作用：

• 先删旧版本：在版本详情页点「Delete release」（提醒下：删了之后原有的下载统计、历史记录就找不回来了，三思）
• 回到Releases页面点「Draft a new release」
• 版本号填和之前一样的（比如v1.0.0），Target选带新提交的分支/提交哈希
• 填好说明后点「Publish release」

这个方法会丢数据，所以除非万不得已，别选这个。

关于修改提交日期：千万别这么干！ #

我得严肃提醒下，绝对不要去修改提交日期。Git的提交哈希是包含时间戳的，改日期会直接改变提交哈希，这会把仓库的历史记录搅乱——如果有其他协作成员已经拉过仓库，还会导致冲突，后续麻烦一堆。而且就算你改了日期，GitHub的Release是靠提交哈希关联的，不是日期，根本没法让旧Release自动包含新提交，纯粹是白费功夫。

总结下来，直接更新现有Release的Target到新提交，是最简单、最安全的解决办法。

内容的提问来源于stack exchange，提问作者Tom Burrows