mercurial - 这是一个好的集中式DVCS工作流程吗？

Question

我倾向于使用来自Subversion的Mercurial，并且我想像使用Subversion一样维护集中化的工作流程。这是我在想什么：

stable (clone on server)
    default (branch)
    development (clone on server)
        default (branch)
        bugs (branch)
            developer1 (clone on local machine)
            developer2 (clone on local machine)
            developer3 (clone on local machine)
        feature1 (branch)
            developer3 (clone on local machine)
        feature2 (branch)
            developer1 (clone on local machine)
            developer2 (clone on local machine)

就分支与克隆而言，此工作流程有意义吗？我有东西吗？

同样，“稳定”克隆是发行版。将“默认”分支作为发行版以及所有其他分支最终合并到其中是否有意义？

Answer 1

在Mercurial中，分支（在同一存储库内用hg分支创建）目前是不可逆的。引入后，您只能通过执行历史记录重写将它们从分支名称空间中删除。这就是为什么我只在项目生存期很短（只有几个功能分支）或分支足够通用才能保持最新状态（例如“稳定”，“错误修正”等）的情况下才创建真实分支的原因。据我所知，分支（与其他所有分支一样）都是在您的控制下在本地创建的，因此，如果有人决定使用分支，那么在拉/推之后该分支也会显示在您的主存储库中。

结果是-在您的结构中-从开发拉到稳定后，您还会将feature1和feature2分支合并到稳定中，这是完全没有用的。因为您在稳定版本上修复了错误，所以将稳定引入开发也将分支错误合并到开发中。您可以尝试通过创建稳定的存储库，将其克隆到开发，在开发中分支到feature1并将开发拉入稳定（在这些步骤之间进行一些更改）来进行尝试：尽管您合并了分支名称，但其名称在稳定状态下仍处于非活动状态

稳定的$ hg分支
默认4：1c3cd0d1a523
Feature2 3：82879465c5f3
Feature1 2：5d7480426f21（无效）
错误1：116860d2d85e（无效）


我记得Git可以删除分支，但是Mercurial正在进行一些开发以赶上该主题。我不确定这是否仍是最新的，所以如果我错了，请纠正我。

[编辑]根据Mercurial Wiki中的Pruning Dead Branches，有4种“删除”分支的方法。真正永久删除分支名称而不仅仅是关闭（取消激活）分支名称的唯一方法是，用干净的历史记录替换存储库。 [/编辑]

据我所知，使用Mercurial时，创建克隆而不是分支更为普遍。我记得去年我从SVN转到Mercurial时与您有相同的想法。通常的方法与集中式版本控制不同，因为分支可以在没有中央控制的情况下随时发生，因此克隆是“分支”而不污染分支名称空间并保持开发分离和灵活的首选方式（您将始终检索如果您提取/克隆包括所有分支的完整存储库，并且如果您只想分支进行测试，则必须选择一个永久的唯一分支名称，这样才能对项目中的每个人都显示出来。尽管这种方法似乎浪费了磁盘空间，并且您需要跟踪分支的位置（通常在用户帐户的某些项目文件夹中以及IDE的内部），但这似乎是一种更加灵活实用的处理方式分支机构。 （与您实际使用时相比，它读起来更加困难。）

到目前为止，在使用Mercurial进行了多个较小的项目后，这对我们公司来说是可行的（每个项目只有几个活跃的开发人员）：

在服务器上：

项目名称-主要
发展被推向那里并从那里拉下来；这是保持团队存储库同步的“权威”开发“分支”

项目名称稳定
如果一个版本被发布/部署，这就是-main被推送到的地方；仅在-stable中完成了错误修复，然后又拉回到-main：根据Mercurial Guide by Bryan O'Sullivan的建议，通常可以将对被认为更稳定的版本（例如，先前版本）的错误修复拉回到development分支，但是可以对development分支进行更改包含较新的不稳定功能，除非发布（或类似）发布，否则不应将其引入维护分支。

在开发人员机器上本地：

projectname-main仅克隆一次，就可以通过拉（+ merge）进行工作并进行同步，并定期推送回服务器。

如果需要“分支”功能，则可以克隆-main（本地或从服务器），并将克隆命名为“ projectname-featuredescription”。为了备份或集中共享，我们还在服务器端创建一个克隆并将其推送到那里。如果功能已准备好用于-main，则将-featuredescription拉入本地-main，合并更改，从服务器拉-main，再次合并，然后将-main推回到服务器。如果在使用-featuredescription时对-main进行了更改，则可以轻松地从-main提取并合并更改（但不回推至-main，因为我们不希望该功能在那里）。

与真实分支相比，不利之处在于，在将变更集与父母之一合并后，您将无法轻松识别它们的来源。但这对我们来说还不是问题（提交消息足够有用，或者功能分支与父存储库合并后，功能分支的分离就没有意义了）。

考虑到更大的项目，我想出了以下类似于集中版本控制的方案，该方案应该可以工作（但我还没有使用）。它依赖对服务器端“权威”存储库的受限写访问，因此仅允许特权开发人员（项目负责人）合并并推送到那里。此外，还有一台CI服务器作为对另一个经过-main-tested的存储库的关守，这是-main的子集，其中仅包含经过CI批准的变更集，并稍有延迟。

在服务器上：

项目名称-主要
发展只有少数人具有写访问权，需要对主要更改进行拉动；他们控制着哪些要素分支被合并

经过测试的项目名称
发展除非出了点问题，否则任何人都不应在这里写东西，因为经过测试意味着持续集成系统成功地构建了-main并将该修订版本推入了-main-tested，因此此处的代码已经过验证，不应破坏编译或测试

项目名称稳定
经过项目名称稳定测试
稳定“分支”的相同策略；和以前一样，我们在发行版中将-main推送到-stable并进行错误修复，-stable-tested已通过CI认证

当然，在团队/开发人员可以将日常工作推向某个地方的地方，因为-main现在仅用于权威性更改（当然，它们可以完全在本地工作，但是如果他们不喜欢，则必须在某个地方进行同步）使用HG服务彼此建立对等关系，或者设置自己的服务器或进行备份）。

减少提交和存储库/分支的另一种方法是使用mq扩展名来处理补丁队列。但是，我发现使用克隆或分支更容易，至少对于小型项目而言更是如此。