我在本地使用 Mercurial 进行项目（这是唯一一个没有推/拉到/从其他任何地方的仓库）。
迄今为止，它有一个线性的历史。但是，我现在正在做的事情是一种糟糕的方法，我想回到开始之前的版本并以不同的方式实现它。
我对Mercurial 中的 // 命令branch有点困惑revert。update -C基本上我想恢复到版本 38（目前是 45），并让我的下一次提交以 38 作为父级并从那里继续。我不在乎修订版 39-45 是否永远丢失或最终陷入自己的死胡同。
我需要哪个命令/命令集？
这是命令的备忘单：
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克隆中仍然会有旧的（坏的）修订。（您可以随意重命名克隆，例如footofoo-bad和foo-38to foo。）
最后，你也可以使用hg revert --all --rev 38然后提交。这将创建一个看起来与修订版 38 相同的修订版 46。然后您将从修订版 46 继续工作。这不会以与之前相同的显式方式在历史记录中创建分叉hg update，但另一方面，您不会抱怨有多个头。hg revert如果我与已经根据修订版 45 制作了自己的作品的其他人合作，我会使用。否则，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）并使用它。然后，您只需右键单击您可能想要返回的修订版 - 所有提交消息都在您眼前 - 并“恢复所有文件”。使在文件集版本之间前后滚动变得直观且容易，如果您想确定问题首次出现的时间，这将非常有用。