首先关闭分支然后将其与默认分支合并（例如）或首先将其合并然后关闭它会更好吗？
例如，在TortoiseHg中，在第一种情况下，您将看到从关闭节点到默认分支的行。在第二种情况下，您将看到从上次提交到默认分支的一行以及从上次提交到关闭节点的额外行。
我希望我很清楚。也许这是一个品味问题...
答案 0 :(得分：22)
这不是品味问题，而且存在差异。简而言之，关闭分支，然后合并。
对于Mercurial分支名称来说仅仅是元数据＆＃34;对于每个变更集。它确实会影响某些命令的结果，例如hg branches忽略关闭的命令，或者hg push默认情况下不允许每个分支添加新的头部。但同样 - 它过滤了。
在内部，Mercurial将存储库视为变更集的图形，DAG具体。该图的拓扑头用于逻辑实现，例如在hg pull期间比较本地和远程存储库时。更多的拓扑头可以（略微但仍然）影响性能 - How do closed branches affect Mercurial performance?。同样数量的它们可能导致在IIS服务器中运行Mercurial 400 Bad Request - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling。
当第一个合并然后关闭时，分支就会关闭 - 好吧，人类默认不会看到该分支。但是，mercurial获得了另一个拓扑头。请看下面的视觉解释。因此先关闭。
close then merge merge then close
---------------- ----------------
@ default, head @ default, head
| |
o merge <--> | x close branch, head
|\ | |
| x close branch <--> o | merge
| | |\|
o | dev on default o | dev on default
| | | |
| o dev on branch | o dev on branch
| | | |
| o open branch | o open branch
|/ |/
o default o default
您可以查看here了解我们如何得出这个结论的详细信息。
答案 1 :(得分：9)
在谈论命名分支时，这两种方法之间没有真正的区别，至少在任何最新版本的Mercurial中都是如此。事情在1.5之前（？）是不同的，但纯粹在hg heads和hg branches将在输出中包含这些“封闭”分支这一事实 - 如果您指定-c，它们仍然可以命令。
记得当你关闭一个分支（使用hg commit --close-branch或在Tortoise中）时，你实际上只需提交一个新的变更集，其中变更的标志设置为分支X已关闭 - 您可以轻松更新到分支并通过执行另一次提交重新打开它。
然而，当重新开启一个分支时，你在Tortoise中看到的“bar”仍然会存在于之前关闭的变更集中，所以仅仅因为这个原因，我个人会选择关闭 - 政策。我认为，在视觉上更具有启发性，看到你正在从你喜欢的东西中融合（因此在合并之前关闭了分支）。
“匿名”分支的情况略有不同，因为它们在合并后不会包含在hg branches输出中，因此不需要明确关闭。
答案 2 :(得分：2)
正如我公司最近发现的那样，有一个很好的理由更喜欢close-them-merge。正如其他答案所讨论的那样，在合并然后关闭时你最终会得到一个额外的＆＃34;拓扑头＃34;而在接近合并时你不会留下这个额外的头。
结果是these extra heads add up，并且最终可能导致同步操作出现问题（Mercurial需要协商哪个头在哪一侧发现要推或拉的变更集）。随着悬空拓扑头数量的增加，这些操作变得越来越大，直到最终they start to fail。值得庆幸的是，您可以非常轻松地clean them up later，但最好首先避免这个问题。