我的工作流是做非常频繁的提交和推送，然后当我准备好时，将提交结合成一个提交（带histedit等）来清理日志。如何在hg中有一个工作流程，哪里有非常频繁的提交？
用git，我会做一个rebase和push。留下的摇摇晃晃的头不会乱丢我的日志，最终会被垃圾收集。
随着mercurial，我结束了多个头。如果我关闭分支以摆脱陈旧的头部，最终会有一百万封闭的分支仍然出现在日志中。这破坏了最初的目的。
如何在没有完全搞砸日志的情况下在mercurial中拥有这样的工作流程？有没有可以在mercurial下工作的替代工作流程？
请注意，频繁的提交也被推送到回购（为了安全起见）。这意味着我不能很好地使用像strip这样的东西。
考虑进化扩展，在this post中有最好的解释，尽管它不是特定于bitbucket的，并且在Mercurial环境中得到了广泛的支持。你可能已经安装了，只需要启用它。
一旦你喜欢它，它是世界上最好的。它允许一个提交替换另一个 - 即使它已经被推送，它也会废弃另一个提交。它可以让你重写提交的方式，不会中断已经推送提交。把它想象成git --amend或git rebase，但对于已经推送过的东西来说是安全的。
当您执行一个废弃一个或多个其他变更集的过程时，为这些变更集推送过时的标记，随后从该回购中抽取的任何人都会将废弃的变更集替换为其历史记录/日志中已废弃的变更集推。过时的变更集仍然存在，但它们不会混淆日志。
我希望我们很快能在git中看到类似的东西 - 一些人已经开始研究类似的功能。
虽然@ Ry4an建议真的的最佳途径（TM），你可以用另一种方式问心无愧唯一的“经典”发布工具
[phases] publish=False推送目标（阅读和神交phases）（见也介绍到阶段）
你*可以*使用'hg strip'，这只是一个很大的痛苦。考虑设置频繁的小提交以使用秘密阶段，以便它们不被推送。如果你确实需要明确地推动它们，那么在之后强制它们回到秘密阶段，并且在需要时/在需要时将它们剥离。 – torek
一旦您将提交推出，Strip将不起作用。我的意思是，它适用于当地的回购协议，但是当你下次回来的时候你可以回复它们。他们永远在回购中。你最终会有多个头。你可以关闭一个分支来摆脱头部，但历史/日志仍然很痛苦地混乱。 下面有一个链接描述清除不需要的分支的3种方法。但是他们都很痛苦，所以这个工作流程非常繁琐。 https://www.mercurial-scm.org/wiki/PruningDeadBranches – Ziffusion
这就是为什么我建议将它们标记为秘密。一旦推动，你必须从每个存储库中'hg strip'，这就是“巨大的痛苦”。 Lazy Badger的建议（禁用辅助备份存储库中的发布）也可行，但现在需要三个仓库：“工作站点”，“辅助备份”和“发布点”。然而，并非所有这些，Evolve扩展显然是在正确的轨道上，我不知道它为什么还不是标准Mercurial的一部分。 – torek