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

我在本地使用Mercurial进行项目（这是唯一的仓库，没有在其他任何地方进行推/拉操作）。

迄今为止，它具有线性历史。但是，我现在意识到的当前工作是一种糟糕的方法，我想在开始之前先回到该版本并以另一种方式实现它。

我对Mercurial中的branch/ revert/ update -C命令有些困惑。基本上，我想恢复到38版（当前为45版），并让我的下一个提交以38作为父级并从那里继续进行。我不在乎39-45修订版是否会永远丢失或最终落入自己的死胡同。

我需要哪个命令/一组命令？

hg update [-r REV]

如果稍后提交，则将有效地创建一个新分支。然后，您可以仅继续在该分支上工作，或者最终将现有分支合并到该分支中。

这是命令的备忘单：

• 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克隆中仍然会有旧的（不好的）修订。（您可以随意将克隆重命名，例如，footo foo-bad和foo-38to foo。）

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

在我完成提交和推送之后，我刚遇到一种需要将一个文件还原到以前的版本的情况。用于指定这些修订的简写语法未包含在其他答案中，因此此处使用此命令

hg revert path/to/file -r-2

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

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

它要求启用mq扩展，并且具有与Martin Geisler建议的“克隆回购方法”相同的限制：如果更改集以某种方式发布，则它可能会在某个时间点返回到您的回购中，因为您仅更改了您的本地仓库。

使用后hg update -r REV，关于如何提交更改的答案尚不清楚，以便您可以进行推送。

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

我必须首先对任何文件进行更改（例如在README中），因此Mercurial意识到我进行了新更改，然后可以提交该更改。

然后，如上所述创建了两个头。

为了在推销之前摆脱其他人的烦恼，我随后遵循了“非操作合并”步骤来纠正这种情况。

这样我就可以推动了。

上面的答案最有用，我学到了很多东西。但是，对我来说，简洁的答案是：

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

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

${1}修订号或分支名称在哪里。这两行实际上是bash脚本的一部分，但是如果您想手动执行，它们可以很好地工作。

如果您需要向发布分支添加修补程序，但需要从默认版本进行构建，这将非常有用（直到我们正确配置CI工具并能够从分支构建，然后再取消发布分支）。

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