我正在尝试确定人们如何使用“分支存储库”，同时还使用subrepos。
假设我有一个repo Main包含一个解决方案文件（.NET），并填充了subrepos A，B，C：
/Main
- A
- B
- C
MainSolution.sln
A，B和C，在其他“主”回购之间共享，非常紧密地集成到主项目中。因此，Main repo的一个主要特性是需要修改subrepos（即它们是共享库，但是非常积极地开发）。
现在是时候添加功能了。此功能对于一个人来说太大了，因此需要将代码推送到中央仓库，以便其他人可以提供帮助。我们还需要能够在功能开发开始之前回到最后的“稳定”代码，以防需要修复错误。我相信在这一点上我有两个选择：（1）在Main repo中创建一个命名分支，或者（2）创建一个Main的新克隆。由于存在subrepos，这两个选项都会产生不典型的反响。
选项1）我认为，创建一个命名分支将允许修改subrepos以进行提交/推送，但是只有其他人也会在他们的Main克隆中更新到该分支，因为.hgsubstate文件被跟踪。然而，subrepos将获得一个新的头，因此（可能）实验功能最终会被推到中央回购。我能正确理解吗？
选项2）有许多倡导者“不使用命名分支，使用'分支存储库'”，它们实际上是主要仓库的克隆，但命名不同并存在于中央服务器上。这对我来说有点吸引力，因为它似乎让事情分离（因此与同事分离 - 因为同事 - 而我自己！ - 仍在学习Mercurial）。但是当涉及子存储库时，这个工作流似乎完全被打破，因为创建主存储库的克隆不会创建子库的新的，分离的克隆。这是一个新的克隆，但它仍然指向相同的子目录，因此对它们所做的更改将找回返回子项目的方式！我意识到这是设计的，对于Mercurial而言，这是一件非常酷的事情（对我而言）。但人们如何在子库中使用此分支存储库工作流？完全不可思议的是，对于每个功能/实验/版本/无论如何，我将在主仓库中创建一个新的克隆（在中央服务器上），并在子目录中创建克隆（在中央服务器上），AND修改所有.hgrc / .hgsub路径以指向正确的中央回购。
此时，我只是想了解人们如何处理复杂的项目并使用subrepos与分支存储库。有什么想法吗？
答案 0 :(得分：3)
您还有其他选择。例如，您可以使用书签。从版本1.9开始，书签可以推送和拉动，它们不仅仅是本地的。由于在新功能完成后，您通常不希望开发“分支”作为命名分支，因此书签通常是此类事物的更好选择。我倾向于使用书签进行新开发，并为已发布的版本保存真正的分支。
您还应该知道子存储库不会以您描述的方式在多个主存储库之间共享 。实际上，您可以将子存储库存储在主存储库中（而不是将它们与主存储库保持在同一级别，或者完全存储在其他位置），这将使它们唯一到每个主存储库，但是当您想要共享这些更改时，您可以从其他主存储库中的子服务器推送和拉出。这就是我通常这样做的方式。
不幸的是，如果没有白板，这很难解释，所以如果不清楚，请告诉我。
答案 1 :(得分：1)
我更喜欢命名分支，这些功能很可能最终会合并到默认分支中。切换分支比切换回购更容易。
使用命名分支，您永远不必担心意外地将不稳定的开发分支推入稳定的仓库。命名分支已经存在，但除非开发人员要求，否则不会通过更新检索。