我对Mercurial很新，但我看到使用Mercurial的一个优点是，在编写功能时，您可以更自由地进行实验，检查更改，共享它们等，同时仍保持“干净”回购完成的功能。
这个问题是历史问题之一。如果我尝试了6种不同的方法来使某些东西发挥作用，那么现在我对所有错误的所有历史都感到困惑。我想要做的是完成并清理我的更改并将它们“折叠”成一个可以推送到共享存储库的变更集。由于我可能从共享存储库中提取新的变更集，并将这些变更集与我自己的变更集混合在一起，这一点很复杂。
我知道这样做的最好方法是使用 hg export 来创建自克隆以来的更改补丁，克隆新的存储库，并将补丁应用到新的存储库。
这些步骤似乎有点麻烦且容易搞砸，特别是如果这种方法推广到整个开发团队，其中一些人有点抵制变化（不要让我开始）。 TortoiseHg使这个过程稍好一些，因为你可以突出显示你想要包含在导出中的变更集。
我的问题是：我是否比这更复杂？是否有更好的工作流程可以用来缓解我的烦恼？期望一个干净的历史，在一个变更集中包含整个（小型）功能是不是太过分了？
或者也许我的整个问题可以通过这种方式总结出来：
mercurial中是否有相同的效果？ Collapsing a git repository's history
答案 0 :(得分：3)
虽然我认为您应该重新考虑在Mercurial中使用分支（根据我对您帖子的评论），但使用命名分支并不能真正帮助您保持无用或不必要的历史记录 - 它只是对它们进行了一些组织。
我会推荐这些工具的组合：
strip永久删除没有子项的任何变更集。完成后，您可以使用mq或histedit来组合，重定位或修改现有提交。 Histedit甚至会让您重做与变更集相关的评论。
一些陷阱：
在您的开头段落中，您提到在功能开发期间共享更改集。请理解，一旦您共享了变更集，使用mq或histedit或strip进行修改并不是一个好主意。使用这些扩展可能会导致修订哈希值发生变化，这会使它们看起来像是其他人的新变更集。
另外，我同意Paul Nathan的观点，即mq（和histedit）是强大的功能，很容易破坏历史。在使用这些扩展之前制作安全克隆是个好主意。
答案 1 :(得分：1)
命名分支是最简单的解决方案。每种实验方法都有自己的分支。这保留了实验的历史。
下一个解决方案是为每个实验准备一个新的克隆。工作的人被推回主要的回购。
下一个解决方案 - 也许你真正想要的 - 是mq扩展，它可以将一系列补丁“压缩”成一个提交。我认为mq是“先进的”，并且“容易意外地在脚下拍摄自己”。我也不在乎压缩我的提交 - 我喜欢将我的版本历史记录作为参考。