清除 Mercurial 中的修订历史记录答案

【问题标题】：Clean revision history in Mercurial清除 Mercurial 中的修订历史记录
【发布时间】：2011-09-14 09:19:20
【问题描述】：

我是 Mercurial 的新手，我仍在尝试建立工作流程。

我克隆了一个远程存储库。然后我对我的本地存储库进行更改并提交。我想推送一个干净的修订历史。我不想推送一些可能只会混淆远程存储库的修订（例如，方法的错字重命名、添加 javadoc、删除空格等）。这可能吗？

谢谢！

【问题讨论】：

您是否希望在保留所有更改的同时完全避免推送某些更改或拥有“干净”的历史记录？
我想避免推动一些变化。我只想推送相关的
可能是可能的，但由于每个提交只包含“差异”，你可能会丢失一些东西。当您谈论重命名方法时，我很担心
我只是在谈论一些小的错字重命名，例如从“execte”到“execute”。其意图没有变化。
另一个例子：我创建了一个名为“execute”的新方法。提交#1。做了一些改动。提交#2。然后我将该方法重命名为“运行”。提交#3。我改变了主意，将其重命名为“执行”。提交#4。我不想推送提交 #3，因为它没有意义。

标签： mercurial

【解决方案1】：

确实，在某些情况下，修剪/剥离/抛光变更集或将私有/进行中和公开/准备好的变更分开是有意义的。以下是一些如何使用 Mercurial 处理此问题的建议：

如果您进行了一系列小提交（这是一件好事），但您更愿意将它们作为一个变更集发布（如果您提交了这很有意义 - 可能是矛盾的 - 快照变更集），请使用 @987654321 @ 扩展：
```
$ hg collapse -r <first-ref>:<last-ref> # both revs including
```
如果您只想将更改保密，而其他更改则要发布，则 (a) 使用 mercurial queues 进行私人更改或 (b) 仅提交您的私人更改在自己的 branch (named, bookmarked, or cloned) 中进行更改，并定期将其与公共分支合并。如果您交替提交私有和公共更改，后者要求您经常在分支之间切换。

更新

为了说明选项 2.b，请考虑以下变更集图：

0--1--4--5---8--9   <= public/stable branch
    \     \
     2--3--6--7     <= private/dev branch

这意味着您已经在 dev 分支上更改了 2 和 3。然后你在 stable 分支上做了一些工作（修订版4 和5）。这些更改在 dev 中也有意义，因此您将它们合并到 dev（修订版 6）。最后，您在 dev 中进行了另一个实验性更改（修订版 7）并在 stable 中进行了一些准备发布的改进（修订版 8 和 9）。您现在可以发布（即推送到远程存储库）在 stable 中所做的更改，方法是运行

$ hg push -r 9     # or `-r stable` if the branch is named or bookmarked as such

所有私有更改都将保留在本地！

请注意，如果您打算稍后完善您的私有提交（例如，将它们折叠到一个变更集），则不得在稳定分支中合并（折叠不能跨合并工作）。相反，rebase 您可以在您希望它们与 stable 中的最新更改同步时进行私有更改。

【讨论】：

在选项 2b 中，当我从我自己的私有分支合并到一个新的“稳定”分支后，我的私有分支的修订历史记录是否也会被推送到远程存储库？
您应该将稳定分支合并到私有分支（反之亦然），即更新到您的私有分支，运行hg merge stable 并提交合并。现在合并是私有分支的一部分，在推送稳定分支时不会发布（例如hg push -r stable 或hg push -r <latest-rev-in-stable>）。
关于合并方向，另见：Differences merging repository A->B vs B->A。
Oben，我明白你的意思，但我还需要将更改推送到远程存储库。我的问题是能够推送一些更改，但不能推送我在私有分支上所做的一些修订。

【解决方案2】：

这更多是关于修订控制系统的问题，而不是关于 mercurial 的问题。我个人会推动一切，你的建议有点违背版本控制系统的目的。

但是，如果您想了解有关 hg 工作流程的更多信息，请尝试查看此guide 或此wiki。

您还可能对rollback 命令感兴趣，它使您能够修复最新的提交。

编辑：我的选择是保留两个分支：一个与远程存储库相同，您只提交“官方”更改，另一个是合并新的官方提交并进行额外的私人提交。

【讨论】：

“你的建议有点违背版本控制系统的目的”：OTOH，git 有很多工具用于“重写历史”以及挑选和清理私有提交到可发布版本。跨度>
绝对正确，这就是我写“个人”的原因 :) 用于 rebase、cherry-picking 等的 Git 工具并没有真正破坏或改变任何东西，旧的提交仍然可以恢复一段时间很久。然而，他并不是在谈论可发布版本的微小变化，他谈到避免推送方法重命名、javadoc ......它们是非常重要的变化。
您可以看看这个guide on branches 以便选择。

【解决方案3】：

如果最后所有的寄生变化都已经完成，你可以简单地剥离它们。

如果没有，你可以尝试使用 Patch Queue 来移除不必要的提交：

将您的更改一一导入 MQ 并取消应用补丁
删除与您不想要的更改相匹配的补丁
重新应用剩余的补丁

这适用于小提交。如果您尝试此操作，请在本地存储库的克隆上执行此操作以避免丢失。

另外，请注意不要更改已经“共享”（推送）的历史记录。

【讨论】：

感谢您的警告。我将尝试探索 Patch Queue。

【解决方案4】：

Histedit 也可以是可用且更简单（比 MQ）编辑历史记录的解决方案

【讨论】：