我在本地使用Mercurial进行项目（这是唯一没有推送/拉动其他任何地方的回购）。
到目前为止，它有一个线性历史。然而，我正在研究的当前事情我现在已经意识到这是一种可怕的方法，我想在开始之前回到版本并以不同的方式实现它。
我对Mercurial中的branch / revert / update -C命令感到困惑。基本上我想恢复到版本38（目前在45）并让我的下一个提交有38作为父母并从那里继续。我不在乎修改39-45是永远丢失还是最终落入他们自己的死胡同。
我需要哪个命令/命令集？
答案 0 :(得分：394)
以下是命令的备忘单：
hg update 会更改您的工作副本父版本，还会更改文件内容以匹配此新的父版本。这意味着新的提交将从您更新的修订版继续进行。
hg revert 仅更改文件内容，并单独保留工作副本父版本。当您决定不想对工作副本中的文件进行未经修改的更改时，通常会使用hg revert。
hg branch 启动新的命名分支。将命名分支视为您分配给变更集的标签。因此，如果您执行hg branch red，则以下变更集将被标记为属于“红色”分支。这可以是组织变更集的一种很好的方法，特别是当不同的人在不同的分支上工作时，您以后想要查看变更集的来源。但是你不想在你的情况下使用它。
如果您使用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然后提交。这将创建一个修订版46，它看起来与修订版38相同。然后，您将继续使用修订版46.这将不会像hg update那样以明确的方式创建历史记录中的分支，但另一方面，您不会抱怨多头。如果我与其他已根据修订版45开展工作的人合作，我会使用hg revert。否则，hg update更明确。
答案 1 :(得分：146)
hg update [-r REV]
如果稍后提交，您将有效地创建一个新分支。然后，您可以继续仅在此分支上工作，或者最终将现有分支合并到其中。
答案 2 :(得分：29)
我刚刚遇到一个需要将一个文件还原到以前版本的情况，就在我完成提交和推送之后。用于指定这些修订的简写语法未包含在其他答案中，因此这是执行此操作的命令
hg revert path/to/file -r-2
-2将恢复到上一次提交之前的版本，使用-1只会恢复当前未提交的更改。
答案 3 :(得分：7)
恕我直言，hg strip -r 39更适合这种情况。
它需要启用mq扩展，并且与Martin Geisler推荐的“克隆repo方法”具有相同的限制： 如果变更集以某种方式发布，它将（可能）在某个时间点返回您的仓库，因为您只更改了本地仓库。
答案 4 :(得分：6)
使用hg update -r REV之后，答案中不清楚如何提交更改以便您可以推送。
如果您只是在更新后尝试提交，Mercurial认为没有任何更改。
我必须先对任何文件进行更改（例如在自述文件中），以便Mercurial认识到我做了一个新的更改，然后我可以提交。
然后如上所述创建了两个头。
为了在推动之前摆脱另一个头，然后我按照No-Op Merges步骤来解决这种情况。
然后我才能推。
答案 5 :(得分：5)
上面的答案最有用，我学到了很多东西。但是，根据我的需要，简洁的答案是：
hg revert --all --rev ${1}
hg commit -m "Restoring branch ${1} as default"
其中${1}是修订号或分支名称。这两行实际上是bash脚本的一部分，但是如果你想手动执行它们，它们可以自行工作。
如果您需要向发布分支添加一个热修复，但需要从默认构建（直到我们正确地使用CI工具并且能够从分支构建并随后取消发布分支），这将非常有用。
答案 6 :(得分：1)
我将安装Tortoise Hg（Mercurial的免费GUI）并使用它。然后，您可以右键单击您可能想要返回的修订 - 在您眼前的所有提交消息 - 以及“还原所有文件”。使文件集版本之间的前后插入变得直观和容易，如果您希望确定问题何时首次出现，这可能非常有用。