Mercurial has a fairly strong opinion on what you should use your default branch for. It's documented in the Standard Branching wiki page. The summary is:
You should not use a name other than default for your main development branch.
The reason is that default is the branch that is checked out by new clones. If you try to use some other name for your "main" branch, users will get a more or less random branch when they clone and commit things in the wrong place, which is generally undesirable.
Even with tons of documentation that says "branch before adding a new feature" (see next point), people will forget this when they send you patches. They then have the trouble of cleaning up things by moving changesets around.
So always put the bleeding-edge code in the default branch and use other branches for your stable releases.
Don't treat branch names as disposable
Branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced. Thus you will want to give some thought to your branch names so that you don't pollute the branch namespace.
Also, if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial and the tools surrounding it are designed to work well with hundreds of branches. Mercurial itself still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow alredy stabilized.
We have caches in place internally in Mercurial, so the problems are mostly UI problems: hosting sites and log viewers might run hg branches to load all 10,000 branches into a single drop-down menu. That is really slow and useless for the poor user that want to select a single branch from the gigantic menu.
If the branches are closed, then they wont show up in hg branches, and so the problem should be minimized. However, the tools might want to show closed branches too — it all depends on the tool.
I'm sorry this is a little vague. The main point is that Mercurial is built to scale in the number of changesets, not the number of named branches. We have addressed the biggest performance problems with named branches with the cache I mentioned before, so today I'm not too concerned about having many branches, especially if the number of open branches is kept small (less than, say, 100).
I have fallen into the habit if using default in Mercurial and master in Git for the actual work, the bleeding edge, and using tags and branches for the releases. hgsubversion and Git-Svn seem to take this tack.
There are not, in common, such thing as "most conventional" - each and every workflow is a matter of local convention and development policy in team.
I saw both mentioned policy often, and intermediate variations - also.
In case of strong testing|release policy and intensively used branches ("branch per task") "default" branch often exist only as merges-only branch (merges from feature-branches before QA-testing) and means "Code, which work with finished features, without throwing errors, but with unstested functionality".
Minor versions form named branches, each release in such branch is tag. Bugfix branches are merged after completing into "default" and active versions branches
But this workflow is just one more example, not better|worse than others, suitable for mid-size teams with responsibility separation established, doesn't work well in "chaotic anarchy" development
里面的金额并不大。如果我们只讨论开发和开发默认的 STABLE 分支主要只是一个命名约定。我倾向于将 DEV 作为默认分支，因为大多数工作都发生在 dev 分支上，如果这是默认分支，那么麻烦就少了。
就我个人而言，我更喜欢每个版本都有一个命名分支。然后，错误修复可以继续在这些分支上进行，并在使用 hg merge 后相对轻松地向前移植到所有版本。如果您尝试对 DEV 和 STABLE 执行相同的操作，则只能有一个维护版本（最后一个），或者您的稳定分支开始增长分支，最终每个版本都会得到一个（可能组织性较差的）分支版本结构。
There's not a huge amount in it. If we're talking about just DEV & STABLE branches, which is default is mainly just a naming convention. I'd tend to have DEV as default, just because most work goes happens on the dev branch and if this is the default branch, it's less hassel.
Personally I prefer a named branch per release. Bugfixes can then go on those branches and be forward ported with relative ease to all releases after using hg merge. If you try to do the same with DEV and STABLE, you can only ever have one maintained release (the last one), or your stable branch starts growing branches and you end up with a (possibly less organised) version of the branch per release structure.
发布评论
评论（4）
Mercurial 对于您应该使用
default分支的用途有相当强烈的意见。它记录在标准分支 wiki 页面中。摘要是：您不应为主开发分支使用
default以外的名称。原因是
default是新克隆签出的分支。如果您尝试为“主”分支使用其他名称，则当用户在错误的位置克隆和提交内容时，他们将或多或少地获得随机分支，这通常是不可取的。即使有大量文档说明“在添加新功能之前进行分支”（请参阅下一点），人们在向您发送补丁时也会忘记这一点。然后，他们会遇到通过移动变更集来清理内容的麻烦。
因此，始终将前沿代码放在
default分支中，并使用其他分支来发布稳定版本。不要将分支名称视为一次性的
分支名称是每个提交的永久部分，并允许识别每个提交是在哪个分支上引入的。因此，您需要考虑一下您的分支名称，以免污染分支名称空间。
此外，如果您尝试对每个错误修复使用一个分支，您最终可能会遇到性能问题。 Mercurial 及其周围的工具旨在与数百个分支机构良好配合。 Mercurial 本身仍然可以很好地处理一万个分支，但某些命令可能会显示出明显的开销，只有在工作流程稳定后您才会看到这些开销。
我们在 Mercurial 内部设置了缓存，因此问题主要是 UI 问题：托管站点和日志查看器可能会运行
hg Branch将所有 10,000 个分支加载到单个下拉菜单中。对于想要从巨大的菜单中选择单个分支的可怜的用户来说，这确实很慢而且毫无用处。如果分支关闭，那么它们就不会出现在
hg 分支中，因此问题应该最小化。然而，这些工具可能也想显示封闭的分支——这一切都取决于工具。抱歉，这有点含糊。要点是 Mercurial 是根据变更集的数量而不是命名分支的数量来构建的。我们已经用我之前提到的缓存解决了命名分支的最大性能问题，所以今天我不太关心有很多分支，特别是如果打开的分支数量保持较小（例如，小于 100）。< /p>
Mercurial has a fairly strong opinion on what you should use your
defaultbranch for. It's documented in the Standard Branching wiki page. The summary is:You should not use a name other than
defaultfor your main development branch.The reason is that
defaultis the branch that is checked out by new clones. If you try to use some other name for your "main" branch, users will get a more or less random branch when they clone and commit things in the wrong place, which is generally undesirable.Even with tons of documentation that says "branch before adding a new feature" (see next point), people will forget this when they send you patches. They then have the trouble of cleaning up things by moving changesets around.
So always put the bleeding-edge code in the
defaultbranch and use other branches for your stable releases.Don't treat branch names as disposable
Branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced. Thus you will want to give some thought to your branch names so that you don't pollute the branch namespace.
Also, if you attempt to use a branch per bugfix, you may eventually run into performance issues. Mercurial and the tools surrounding it are designed to work well with hundreds of branches. Mercurial itself still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow alredy stabilized.
We have caches in place internally in Mercurial, so the problems are mostly UI problems: hosting sites and log viewers might run
hg branchesto load all 10,000 branches into a single drop-down menu. That is really slow and useless for the poor user that want to select a single branch from the gigantic menu.If the branches are closed, then they wont show up in
hg branches, and so the problem should be minimized. However, the tools might want to show closed branches too — it all depends on the tool.I'm sorry this is a little vague. The main point is that Mercurial is built to scale in the number of changesets, not the number of named branches. We have addressed the biggest performance problems with named branches with the cache I mentioned before, so today I'm not too concerned about having many branches, especially if the number of open branches is kept small (less than, say, 100).
我已经养成了这样的习惯：在 Mercurial 中使用默认值，在 Git 中使用 master 来进行实际工作、前沿技术，并使用标签和分支进行发布。 hgsubversion 和 Git-Svn 似乎采取了这种策略。
I have fallen into the habit if using default in Mercurial and master in Git for the actual work, the bleeding edge, and using tags and branches for the releases. hgsubversion and Git-Svn seem to take this tack.
一般来说，不存在“最常规”之类的东西 - 每个工作流程都是本地约定和开发策略的问题团队。
我经常看到提到的政策，以及中间的变化。
在强大的测试|发布策略和密集使用的分支（“每个任务分支”）的情况下，“默认”分支通常仅作为仅合并分支存在（在 QA 测试之前从功能分支合并），并且意味着“代码，与完成的功能，不会引发错误，但功能未经测试”。
小版本形成命名分支，该分支中的每个版本都是标签。 Bugfix分支在完成后合并为“默认”和活动版本分支
但是这个工作流程只是又一个例子，并不比其他更好|更差，适合建立了责任分离的中型团队，不'在“混乱的无政府状态”开发中表现良好
There are not, in common, such thing as "most conventional" - each and every workflow is a matter of local convention and development policy in team.
I saw both mentioned policy often, and intermediate variations - also.
In case of strong testing|release policy and intensively used branches ("branch per task") "default" branch often exist only as merges-only branch (merges from feature-branches before QA-testing) and means "Code, which work with finished features, without throwing errors, but with unstested functionality".
Minor versions form named branches, each release in such branch is tag. Bugfix branches are merged after completing into "default" and active versions branches
But this workflow is just one more example, not better|worse than others, suitable for mid-size teams with responsibility separation established, doesn't work well in "chaotic anarchy" development
里面的金额并不大。如果我们只讨论开发和开发默认的 STABLE 分支主要只是一个命名约定。我倾向于将 DEV 作为默认分支，因为大多数工作都发生在 dev 分支上，如果这是默认分支，那么麻烦就少了。
就我个人而言，我更喜欢每个版本都有一个命名分支。然后，错误修复可以继续在这些分支上进行，并在使用 hg merge 后相对轻松地向前移植到所有版本。如果您尝试对 DEV 和 STABLE 执行相同的操作，则只能有一个维护版本（最后一个），或者您的稳定分支开始增长分支，最终每个版本都会得到一个（可能组织性较差的）分支版本结构。
There's not a huge amount in it. If we're talking about just DEV & STABLE branches, which is default is mainly just a naming convention. I'd tend to have DEV as default, just because most work goes happens on the dev branch and if this is the default branch, it's less hassel.
Personally I prefer a named branch per release. Bugfixes can then go on those branches and be forward ported with relative ease to all releases after using
hg merge. If you try to do the same with DEV and STABLE, you can only ever have one maintained release (the last one), or your stable branch starts growing branches and you end up with a (possibly less organised) version of the branch per release structure.