【发布时间】：2013-06-18 12:46:13
【问题描述】：
是先关闭分支然后将其与默认分支合并（例如）还是先合并然后关闭它更好？
例如，在 TortoiseHg 中，在第一种情况下，您会看到一条从关闭节点到默认分支的线。在第二种情况下，您将看到从最后一次提交到默认分支的一行，以及从最后一次提交到关闭节点的额外行。
我希望我很清楚。也许这是一个品味问题......
【问题讨论】：
标签： mercurial tortoisehg
【发布时间】：2013-06-18 12:46:13
【问题描述】：
这不是口味问题，是有区别的。简而言之，关闭分支，然后合并。
Mercurial 分支名称只是每个变更集的“元数据”。它确实会影响某些命令的结果，例如 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，了解我们如何得出此结论的详细信息。
【讨论】：
在谈到命名分支时，这两种方法之间没有真正的区别，至少在任何最新版本的 Mercurial 中是这样。 1.5 之前的情况有所不同（？），但纯粹是因为 hg heads 和 hg branches 将在其输出中包含这些“关闭”分支 - 如果您在命令中指定 -c，它们仍然可以。
请记住，当您关闭分支（使用hg commit --close-branch 或在 Tortoise 中）时，您实际上只是提交了一个新的变更集，其中该变更设置了一个标志以表示分支 X 已关闭 - 您可以轻松更新到该分支并重新- 通过执行另一个提交来打开它。
但是，当重新打开一个分支时，您在 Tortoise 中看到的“栏”仍将存在于先前关闭的变更集中，因此仅出于这个原因，我个人会选择 close-then -合并政策。我认为，看到你是从你喜欢的东西中合并（因此在合并之前关闭了分支）更具视觉指导性。
与“匿名”分支略有不同，因为它们在合并后不包含在 hg branches 输出中，因此不需要显式关闭。
【讨论】：
-
并且“关闭然后合并”也可以最小化更新。 “关闭 -> 更新到主分支 -> 合并”比“更新到主分支 -> 合并 -> 更新到合并的分支 -> 关闭它 -> 再次更新到主分支”更简单
正如我的公司最近发现的那样，有一个很好的理由更喜欢近距离合并。正如其他答案所讨论的那样，在 merge-then-close 中，您最终会得到一个额外的“拓扑头”，而在 close-then-merge 中，您不会留下这个额外的头。
结果是these extra heads add up，最终会导致同步操作出现问题（Mercurial 需要协商哪些头在哪一边以发现要推送或拉取的变更集）。随着悬空拓扑头数量的增加，这些操作变得越来越大，直到最终they start to fail。值得庆幸的是，您可以很容易地clean them up later，但最好一开始就避免这个问题。
【讨论】：