在Mercurial中，分支（在同一个存储库中使用hg分支创建）目前是不可逆的。一旦引入，您只能通过执行历史重写将它们从分支名称空间中移除。这就是为什么如果项目生命周期很短（只有少数功能分支）或分支足够通用以保持多年（如“稳定”，“错误修正”等），我才会创建真正的分支。据我所知，分支机构（和所有其他产品一样）在没有你的控制的情况下在本地创建，所以如果有人决定使用分支，该分支将在拉/推之后显示在主存储库中。
效果是 - 在你的结构 - 从发展拉入稳定后，你也会得到特征1和特征2分支合并为稳定，是相当无用的。拉稳定到发展因为你固定错误在稳定版本也将合并分支错误到发展。您可以尝试通过创建稳定库，将其克隆到发展，分公司特征1在发展和拉发展到稳定（提交这些步骤之间的一些变化）：分支名字会与非活动的头出现在稳定虽然你它合并：
stable $ hg branches
default 4:1c3cd0d1a523
feature2 3:82879465c5f3
feature1 2:5d7480426f21 (inactive)
bugs 1:116860d2d85e (inactive)
我记得，Git是能够删除分支，但水银有一定的发展能上的猫讨论这个话题;我不确定这是否仍然是最新的，所以如果我错了，请纠正我。
[编辑]根据Mercurial wiki中的Pruning Dead Branches，有4种方法可以“移除”一个分支。真正永久的唯一途径删除分支名称，而不仅仅是关闭（取消激活），它是通过用已清除的历史记录替换存储库。
从我所听到和看到的，使用Mercurial时创建克隆而不是分支更常见。我记得去年当我从SVN转到Mercurial时，和你有同样的想法。通常的做法与中央版本控制不同，因为分支可以在任何时候发生，而无需集中控制它，所以克隆是“分支”以不污染分支名称空间并保持开发分离和灵活的首选方式（您将始终检索完整的存储库，如果你拉/克隆包括所有分支机构，如果你只是想分支测试的东西，你将不得不选择一个独特的分支名称是永久性的，因此将出现在项目中的每个人）。尽管这种方法似乎浪费了磁盘空间，并且需要跟踪分支机构的位置（通常位于用户帐户和IDE内的某个项目文件夹中），但它似乎是一种更加灵活和实用的处理方式分支机构。 （它读取比当你真正自己使用它更困难）
已经有一些使用水银较小的项目，这是我们公司什么工作至今（每个项目只有几个活跃的开发者）：
在服务器上：
项目名称，主要
发展被推到并从那里拉;这就是“权威”开发“分支”，以保持团队的库同步
项目名称稳定
如果一个版本得到释放/部署这就是- 主被推向;只有错误修正是在- 稳定的完成，然后拉回到- 主要：根据Mercurial Guide by Bryan O'Sullivan的建议，修正了被认为更稳定的版本（例如，以前的版本）通常可以撤回到开发分支中，但开发分支中的更改可能包含更新的不稳定功能，除非发布发布（或类似），否则不应将其拉入维护分支。
本地开发者的机器：
项目名称，主要克隆一次，正在处理和同步做一个拉（+合并），并定期推回服务器。
如果有一个功能“分支”需要我们克隆- 主（本地或服务器），并将其命名为克隆“项目名称 - featuredescription”。为了备份目的或集中式共享，我们还在服务器端创建一个克隆并推送到那里。如果要素是准备- 主，我们拉-featuredescription到我们当地- 主，合并更改，拉- 主从服务器，再次合并，推动- 主回服务器。如果变化发生- 主而我们在-featuredescription工作，我们可以很容易地从- 主拉和合并的变化（不推回- 主但因为我们不希望该功能在那里然而）。
与真正的分支相比，不利的一面是，在与父母合并后，您无法轻易识别出哪些变更集来自哪里。但是这对我们来说还没有问题（提交消息足够有用，或者一旦将特征分支与其父库进行合并，则特征分支的分离是无趣的）。
思考更大的项目我想出了以下应该工作的方案（但我还没有使用它）类似于集中版本控制。它依赖于对服务器端“权威”存储库的有限写访问，因此只有特权开发者（项目负责人）才可以合并并推送到那里。此外，还有一台CI服务器作为另一个存储库的网守- 主要测试的，它是- 主要的一个子集，仅包含CI批准的变更集，并略有延迟。
在服务器：
项目名称，主要
发展;只有少数人有写权限，主要变化需要由他们拉动;他们是在什么特征的分支合并
控制
项目名称，主要测试
发展;没有人应该在这里写，除非出现了问题，因为测试意味着持续集成系统，成功地建立了- 主推那个版本为- 主要测试，所以在这里的代码进行验证，不应该打破编译或测试
的projectname稳定
的projectname稳定测试
要稳定的 “分支” 相同的策略;和以前一样，我们推- 主上发布和bug修正工作，稳定版稳定版，测试是CI批准
当然，我们需要有多个仓库的地方在那里的球队/开发者实际上可以推动他们的日常工作，因为-主现在仅用于权威性更改（当然，他们可以完全在本地工作，但他们必须同步某处，如果他们不喜欢使用hg serve彼此同步或设置自己的服务器或关心备份）。
减少提交和存储库/分支的另一个选择是使用mq扩展来处理修补程序队列。但是，我发现使用克隆或分支更容易，至少对于小型项目来说。