将实验记录保存在Mercurial的共享存储库中

Question

我对Mercurial相当陌生，但我看到使用Mercurial的一个优点是，在编写功能时，您可以更自由地进行实验，检入更改，共享它们，等等，同时仍然保持完成特征的“干净”回购。

这个问题是历史问题之一。如果我尝试了6种不同的方式来完成某些工作，现在我坚持了所有的历史来应对所有的错误。我想要做的是通过并清理我的更改并将它们“折叠”成一个可以推入共享存储库的变更集。这很复杂，因为我可能从共享存储库中提取新的变更集，并将这些变更集与我自己的变更集混合在一起。

我知道这样做的最好方法是使用hg export来创建自克隆，克隆新存储库并将修补程序应用到新存储库后所做更改的修补程序。

这些步骤似乎有点麻烦，容易搞砸，特别是如果这种方法被推广到整个开发团队，其中一些人有点改变（不要让我开始）。 TortoiseHg使这个过程稍微好一点，因为您可以突出显示要包含在导出中的变更集。

我的问题是这样的：我是否会让它比需要的更复杂？有更好的工作流程可以用来缓解我的烦恼吗？期望在一个变更集中包含整个（small-ish）特性的清晰历史是否太多了？

或者，也许我的整个问题可以这样概括：

是否有善变这等同？ Collapsing a git repository's history

Answer 1

尽管我认为你应该重新考虑你在Mercurial中使用分支（根据我对你的帖子的评论），使用命名分支并不能真正帮助你维护无用或不必要的历史 - 它只是组织它们一点点。

我建议这些工具的组合：

1. mercurial queues
2. histedit（不与汞分布）
3. 的MQ变更条功能

之前返工凌乱的历史推向一个幸运的或主要的回购。最简单的方法是使用strip永久删除没有孩子的变更集。完成之后，您可以使用mq或histedit来合并，重定位或修改现有的提交。Histedit甚至可以让您重做与变更集相关的评论。

一些缺陷：

在你的开头一段你提到的功能发育过程中共享的变更。请理解，一旦你分享了变更集，使用mq或histedit或strip去修改并不是一个好主意。使用这些扩展可能会导致修订散列的更改，这会使其看起来像其他人的新变更集。

此外，我同意Paul Nathan的评论：mq（和histedit）是权力特征，可以轻易破坏历史。在使用这些扩展之前制作安全克隆是个好主意。

Answer 2

命名分支是最简单的解决方案。每个实验方法都有自己的分支。这保留了实验的历史。

下一个解决方案是为每个实验都有一个新的克隆。工作人员被推回主仓库。

下一个解决方案 - 可能是您真正需要的 - 是mq扩展，它可以将一系列补丁压缩为单个提交。我认为mq是“先进的”，并且“容易意外地在脚下射击自己”。我也不在乎压缩我的提交 - 我喜欢将我的版本历史记录作为参考。