我经常使用Mercurial命名的分支机构来从事工作和爱好，并且我认为我对它们的理解相当好。我还认为我理解了命名分支与未命名/匿名分支之间的区别。但是一个工作小组遇到了一个问题，我承认我有些困惑，现在我在质疑自己的理解以及我一生的决定。
编码人员正在使用其默认/未命名的开发线：
A -> B -> C
然后，他们为辅助任务做了一些小的提交，目的是稍后再更新回祖先并在那里恢复正常签入。也就是说，首先要做：
A -> B -> C -> D -> E -> F
然后将更多内容提交给C：
/-> D -> E -> F (unnamed branch for later)
/
A -> B -> C ---> G (new tip)
他们的计划是将来某个时候回到F。因此，他们做了所有这些； G的工作还在继续，图表的那部分一直是从G到M的惊人直线。
现在，他们想要同步其仓库，目标存储库停止在B位置。（无论是推入还是拉入都是可行的，因此他们将使用支持所需任何选项的任何一种方法。）图
A -> B -> C -> G -> ... -> M
应该被推/拉。 D->E->F分支在拓扑上是无关的，并且（据我所知）不应视为G以后的祖先。但是尝试在目标存储库上进行操作
hg incoming -r M /path/to/above/repo
hg incoming -r M -b default /path/to/above/repo
正确地找到了B作为最近的共同祖先，但是随后它决定所有比B都要“更新”的变化，而不是沿着从M到B的分支的变化。
得承认，我不确定如何排除一些未命名的分支分支。就我个人而言，我通常在C处克隆仓库，然后在克隆中通过F提交D，但这就是为什么我从未遇到过这种情况并且无法回答他们的问题的原因。我发现了很多“分支指南”，它们解释了如何将F合并回M，以及如何确保D->E->F分支 被远程推送（--new-branch） ，以及有关如何消除分支影响的几篇文章（--close-branch的变体和无操作合并），但我已经知道并使用了所有这些内容；我在如何简单地在整个拉动过程中将其留在上画一个空白。
我们玩了一段时间之后，找不到执行此操作的选项，他们最终的解决方案是克隆包含分支的仓库，然后剥离分支变更集，最后进行同步。每个人都同意这有点疯狂，但至少让他们的团队再次取得进步。我希望下次能找到更好的东西。
答案 0 :(得分：3)
最简单的方法是将这些提交标记为 secret ，这样它们根本就不会被导出。那不是你问的，而是我要做的。但是，我认为忽略该选项的简短答案是您不能，至少不能直接这样做。但这可能是错误的。也许可以使用Convert extension。
Mercurial文档喜欢称这些匿名分支，但我认为这个词不明智。我只称它们为 daglets ，它由一个选定的（通常是线性的）提交链组成，这些提交通向每个头部。 Mercurial 中的分支是命名实体。每个提交仅存在于一个分支上。当您遇到default分支具有提交的情况时：
D--E--F
/
A--B--C--G
您真正拥有的是一个名为default的一个分支，它具有七个提交和两个头。目前，一个人的头被命名为tip的事实并不重要，因为我们可以使用commit X轻松创建一个新分支H：
default: D--E--F
default: /
default: A--B--C--G
\
X: H
，现在tip表示提交H，而不是提交G。分支default继续存在，有七个分支和两个头。当您将两个hg存储库连接在一起时，它们将根据（命名的）分支传输提交。
convert扩展名允许您跳过和/或重新映射图形的各个部分。您可能会使用它来阻止D-E-F进入和/或将它们拼接到另一个分支中。进行这项工作似乎需要很多时间（和精力），因此并不是特别可行。