如何最好地关闭Mercurial分支？

Question

先关闭一个分支再将其与默认分支合并（例如），还是先合并再关闭？

例如，在TortoiseHg中，第一种情况下，您会看到从关闭节点到默认分支的连线。在第二种情况下，您会看到从最后提交到默认分支的连线以及从最后提交到关闭节点的额外连线。

我希望我的意思表达清楚了。也许这只是一种口味问题...

- Lieven Cardoen

Answer 1

这不是品味问题，而是有所区别。简而言之，先关闭分支，再合并。

对于Mercurial分支名称来说，它只是每个变更集的“元数据”。它确实会影响某些命令的结果，例如hg branches会省略已关闭的分支，或者hg push默认情况下禁止在每个分支上添加新的头。但是，这只是过滤作用。

在内部，Mercurial将存储库视为变更集的图形，具体来说是DAG。该图形的拓扑头用于逻辑实现，例如在比较本地和远程存储库期间进行hg pull时。拓扑头数量越多，可能会（稍微）影响性能-如何关闭分支会影响Mercurial性能？。同样，其中一些数量可能会导致Mercurial在IIS服务器中运行时出现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

您可以在这里查看我们得出结论的详细信息。

- Ilia Barahovsky

Answer 2

在谈到命名分支时，至少在Mercurial的任何最新版本中，这两种方法没有实质上的区别。在1.5之前有所不同(?), 但纯粹在于hg heads和hg branches会在它们的输出中包含这些“关闭”的分支 - 如果在命令中指定了-c，则仍然可以包括它们。

请记住，当你关闭一个分支(使用hg commit --close-branch或者Tortoise)时，你实际上只是提交一个新的变更集，其中的改变设置了一个标志来说明X分支已关闭-你可以轻松地更新到该分支并重新打开它，只需执行另一个提交即可。

然而，在重新打开一个分支时，你在Tortoise中看到的"bar"仍将存在于先前关闭的变更集中，因此仅出于这个原因，我个人会选择先关闭再合并的策略。我认为，这更具有视觉指导性，看到你是从一些你满意的东西合并过来的(因此在合并之前关闭了该分支)。

对于"匿名"分支，事情稍有不同，因为在它们被合并后，它们不会包含在hg branches的输出中，因此不需要显式关闭。

- icabod

---

而且，“关闭再合并”也可以最小化更新。相比之下，“关闭->更新到主分支->合并”比“更新到主分支->合并->更新到合并的分支->关闭它->再次更新到主分支”更简单。 - Nashev

Answer 3

作为我公司最近发现的，有很好的理由偏爱先关闭再合并。正如其他答案所讨论的那样，在先合并再关闭的情况下，你会得到一个额外的“拓扑头”，而在先关闭再合并的情况下，你不会留下这个额外的头。

事实证明这些额外的头会累积起来，最终可能会在同步操作中引起问题（Mercurial需要协商哪些头位于哪一侧以发现要推送或拉取的变更集）。随着悬空拓扑头数量的增加，这些操作会越来越大，直到它们开始失败。幸运的是，你可以相当容易地稍后清理它们，但最好还是避免这个问题。

- Chris Phillips