Mercurial — 恢复到旧版本并从那里继续

这是命令的备忘单：

hg update 更改您的工作副本父修订，并更改文件内容以匹配此新父修订。这意味着新的提交将从您更新到的修订版继续进行。

hg revert 仅更改文件内容并单独保留工作副本父修订。当您决定不想在工作副本中保留对文件所做的未提交更改时，通常会使用 hg revert。

hg 分支开始一个新的命名分支。将命名分支视为您分配给变更集的标签。因此，如果您执行 hg 分支红色，则以下变更集将被标记为属于“红色”分支。这可能是组织变更集的好方法，尤其是当不同的人在不同的分支上工作并且您稍后想查看变更集的来源时。但是你不想在你的情况下使用它。

如果您使用 hg update --rev 38，那么变更集 39–45 将成为死胡同——我们称之为悬垂的头部。推送时会收到警告，因为您将在推送到的存储库中创建“多个头”。警告就在那里，因为留下这样的头脑有点不礼貌，因为他们建议有人需要进行合并。但在您的情况下，您可以继续hg push --force，因为您确实希望让它挂起。

如果您尚未将修订版 39-45 推送到其他地方，那么您可以将它们保密。这非常简单：使用 hg clone --rev 38 foo foo-38，您将获得一个新的本地克隆，其中最多仅包含修订版 38。您可以继续在 foo-38 中工作并推送您创建的新（好的）变更集。您的 foo 克隆中仍会有旧的（坏的）修订。 （您可以随意重命名克隆，例如，将 foo 重命名为 foo-bad，将 foo-38 重命名为 foo。）

最后，您还可以使用 hg revert --all --rev 38 然后提交。这将创建一个看起来与修订版 38 相同的修订版 46。然后您将从修订版 46 继续工作。这不会以与 hg update 相同的显式方式在历史记录中创建分叉，但另一方面您不会得到抱怨有多个头。如果我与其他已经根据修订版 45 制作了自己的作品的人合作，我会使用 hg revert。否则，hg update 更明确。

---

hg update [-r REV]

如果稍后您提交，您将有效地创建一个新分支。然后你可能会继续只在这个分支上工作，或者最终将现有的分支合并到其中。

---

我刚刚遇到了一个需要将一个文件恢复到以前的版本的情况，就在我完成提交和推送之后。其他答案未涵盖用于指定这些修订的简写语法，因此这里有执行此操作的命令

hg revert path/to/file -r-2

-2 将恢复到上次提交之前的版本，使用 -1 只会恢复当前未提交的更改。

---

恕我直言，hg strip -r 39 更适合这种情况。

它需要启用 mq 扩展，并且与 Martin Geisler 推荐的“克隆 repo 方法”具有相同的限制：如果更改集以某种方式发布，它将（可能）在某个时间点返回到您的 repo，因为您只更改了你的本地仓库。

---

使用 hg update -r REV 后，答案中并不清楚如何提交该更改以便您可以推送。

如果您只是在更新后尝试提交，Mercurial 不会认为有任何更改。

我必须首先对任何文件进行更改（比如在自述文件中），以便 Mercurial 识别出我进行了新更改，然后我可以提交。

如前所述，这随后产生了两个头。

为了在推动之前摆脱另一个头部，我随后按照 No-Op Merges 步骤来纠正这种情况。

然后我就可以推了。

---

上面的答案是最有用的，我学到了很多。但是，对于我的需要，简洁的答案是：

hg revert --all --rev ${1}

hg commit -m "Restoring branch ${1} as default"

其中 ${1} 是修订号或分支名称。这两行实际上是 bash 脚本的一部分，但如果您想手动执行它们，它们本身就可以正常工作。

如果您需要向发布分支添加热修复，但需要从默认构建（直到我们获得正确的 CI 工具并能够从分支构建并且稍后也取消发布分支），这将非常有用。

---

我会安装 Tortoise Hg（Mercurial 的免费 GUI）并使用它。然后，您只需右键单击您可能想要返回的修订版 - 所有提交消息都在您眼前 - 并“恢复所有文件”。使在文件集版本之间前后滚动变得直观且容易，如果您想确定问题首次出现的时间，这将非常有用。

---