我喜欢命名分支的灵活性，但我对头部的增加有一些担忧。
即使分支关闭，它仍会显示在头部。我知道如何清理“hg head”的输出 我向大师们提问：“我错过了什么？”
首先你可能会问，为什么我要完全隐藏指定分支的头部？出于各种原因：
编辑：事实证明，头部的增加是我使用的旧版本mercurial的症状。关闭分支会将分支的头部隐藏在较新的Mercurial版本上。
我的想法是有一个“死”的头部分支，所有这些封闭的分支头将合并到其上。
死角将由变更集0作为父级，其唯一目的是捆绑现在不需要的流浪头。
该死角只有其他死角子项，它们永远不会合并回默认分支。
答案 0 :(得分：7)
您可以使用hg commit --close-branch将分支标记为已关闭：
http://www.selenic.com/mercurial/hg.1.html#commit
默认情况下，封闭的分支机构不会显示在hg branches或hg heads中（仅当指定了-c / --closed选项时），所以我不确定你看到“混乱”了吗？
通过合并你会得到什么？
答案 1 :(得分：1)
离开死人头部似乎有一个不利因素，以后的Mercurial版本无法解决这个问题。
假设您有许多已关闭的分支头且只有一个非关闭的活动分支。进一步假设在稍后的某个时刻，你会在非闭合头（rev good）之上做出错误的提交（rev bad）。在你推动之前，你想要克隆你的存储库，丢弃那个糟糕的提交。这通常是一件简单的事情 -
hg clone --rev good BadRepo FixedRepo
遗憾的是，由于它们不是rev good的祖先，因此不会拉动封闭的分支头。所有关闭的分支都不会在克隆的存储库中关闭。我用Mercurial 2.3.1进行了测试。
思想？
P.S。 hgflow扩展在合并之前会关闭功能并释放分支。这避免了封闭的头部问题。
关于克隆是一种丑陋的方法，它对我来说非常好用。克隆使用错误提交替换存储库。克隆是本地的努力。那个坏的存储库就被丢弃了。我通常意识到我很快就犯了错误。
-b选项只是通过使用分支名称而不是更改集标识符来重新定义--rev的方法。使用--rev选项会将整个拓扑树拉到修订版本下。如果修订版是分支的头部，则--rev clone与-b clone相同。 -b留下了我用--rev选项描述的相同问题。在原始存储库中关闭的分支如果被保留为头，则会重新打开。
如果模式是要留下封闭的头部，那么它们将很快超过相关的头部。除非你做一个完整的克隆，否则将这些闭包放到克隆中是非常有用的。
答案 2 :(得分：0)
我觉得我已经混淆了水域，为什么我可以做部分克隆。我会更仔细地重申我对封头的关注。
对于从存储库X到存储库Y的任何部分克隆，如果存储库X中存在具有封闭头的分支B，并且该分支包含在克隆中纯粹出于拓扑原因，则分支B将不会在存储库Y中关闭此外，如果合并模式通常会留下封头，那么封头的数量是有序开发时间。
这是我关注的问题，所以在合并之前关闭我的分支机构。我使用hgflow（http://nvie.com/posts/a-successful-git-branching-model）。一个可能的部分克隆是克隆开发分支，然后通过拉动主分支（例如，如果你想消除死角）。如果功能和发布分支在最终合并后已关闭，那么这些分支将在克隆中重新打开。