阻止开发人员在DVCS上提交错误的分支

问题

我在一个大约有10个开发人员的软件项目中，我们通过Mercurial共享源代码。每个版本都有一个开发和生产分支。在项目进行过程中，我们反复从一个分支（即v1）获取源代码，以进入补丁和维护分支以获取早期版本的软件（即v2）。

如果我们没有注意到代码进入错误的分支，则这将导致花费时间来撤消错误的提交，或者导致错误的代码（可能是非QAd）到达并部署在错误的分支中。

我们的分支和合并设计/方法

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

因此，我们将在发布开发分支上工作，直到它准备就绪为止，然后将其分支到一个测试/ UAT /生产分支，在此完成所有发布和维护。标签用于构建该分支的发行版。在测试v1时，将为v2建立一个分支，并且开发人员将开始开发新功能。

趋于发生的事情是，开发人员将由于v2-dev分支而提交的工作提交到v1-dev或v1-prod中，或更糟糕的是，他们将v2-dev合并到v1-prod中（或类似的错误）。

我们告诉大多数开发人员不要访问-prod分支，但是代码仍然会潜入。一组更高级的开发人员“照看” -prod分支。

应该注意的是，尽管v2才刚刚开始开发，但v1中可能仍然有一些相当大的补丁程序可以解决问题。即v1可能不仅获得了奇怪的小补丁。

到目前为止我们尝试过的

• 有一个单独的-prod分支，带有网守。-prod分支应通过其名称发出警告，并且大多数开发人员不必永远都位于该分支中。这并没有真正减轻问题。
• 在开发人员中提高了对此问题的意识，以使他们更加警惕。再次，这不是很成功。

我认为开发人员承诺使用错误分支的可能原因

• 过于复杂的分支机构设计
• 在多个分支并行发展中。（该项目确实表现出使用雪崩模型的症状。）
• 开发人员对DVCS的了解不够充分

我读过的与某些问题相关的问题

我读过这个问题上不承诺到错误的分支，我觉得对于视觉线索的答案可能会有所帮助。但是，我并不完全相信，我们所遇到的问题不是更根本问题的征兆。

通过视觉线索，我们可以轻松地将它们合并到命令行中，但是大约有一半的团队使用Eclipse，我不确定如何合并视觉线索。

题

我们可以使用什么方法，以软件，项目管理或治理的形式来减少（理想地停止）错误的分支，从而占用我们的时间或弄脏我们已部署的代码？

对于我认为可能会做出上述贡献的原因的具体评论，将不胜感激，但这不应该限制您的答复。

问题在于您正在更改过程中分支的含义。

最初，该v1 dev分支用于开发。所有新功能都去了那里。在将来的某个时候，它将成为该分支的维护v1 release分支。这是问题的症结所在。

开发人员不是草率的，分支的权限和角色是草率的并且会随时更改。

您需要做的是建立每个分支的角色，并保持该角色。如果角色更改，则分支。

例如：

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

在此模型中，开发人员始终致力于开发。如果要构建修补程序，则将修补程序检入该发行版的分支（或者更好的是，将发行版分支分支到一个修补程序，然后将其合并回发行版分支）。

您应该阅读的一篇文章（可能是对“应该”的轻描淡写）是Stephen Vance 撰写的Advanced SCM Branching Strategies。

^{在本文中，我首先从广义上定义分支。然后，我讨论各种分支策略，从明显的策略开始，逐步发展到更适合于较大规模开发工作的策略。在此过程中，我将讨论每种策略的优缺点，并利用它们来激发构成更复杂策略的变更...}

在本文中，他确定了分支机构可能具有的五个角色。有时分支可能会同时担任两个角色，并且角色角色中间的分支策略不变时，角色不一定需要新的分支（您有时会看到“不兼容策略分支”）。

这些角色是：

1. 主线。这是分支的来源。总是从主线分支使合并变得容易，因为两个分支将具有一个共同的祖先，该祖先不在一个分支之间分支。
2. 发展。这是开发人员检入代码的地方。一个可能具有多个开发分支，以将高风险更改与常规更改和普通更改隔离开来。
3. 保养。错误修复了现有的生产环境。
4. 积累。合并两个分支机构时，可能不希望冒险破坏主线。因此，分支主线，将分支合并到累加器中，一旦事情解决，就合并回到主线。
5. 打包。打包发布发生在打包分支中。这通常成为发行版，并用于将发行工作与开发隔离开来。请参阅如何处理破坏长时间运行的发行版本的不良提交？以包装与开发冲突为例。

在您的示例中，您有一个级联的主线（这是一个问题-它使合并变得更加困难-如果要将v1的修订合并到v2和v3中会发生什么？），一个dev分支变成了一个维护分支（政策变更，这是一个问题）。

好的，您说的很棒，但这是为perforce编写的，它是一个集中式VCS-我正在使用DVCS。

让我们看一下git-flow模型，看看它如何应用。

主分支（蓝色）是发布分支-用于标记。它不是主线。主线实际上是开发分支（黄色）。释放分支（绿色）是包装角色。低风险开发发生在主线上，高风险开发发生在功能分支（粉红色）中。在此模型中，积累是在开发分支中完成的。维护被视为红色的“修补程序”。

尽管角色策略并不完全匹配（每种产品的生命周期都有其稍有不同），但它们是完全匹配的。

这样做应该简化您的分支策略，并使每个参与人员都更轻松。

当您尝试使用带有网守的单独的-prod分支时，听起来好像是使用一个存储库来实际进行生产构建。如果生产构建仅是通过生产存储库完成的，并且只能由它的网守写入，那么开发人员将无法继续进行生产。这给看门人带来了负担，看门人只有在审核后才能推送到生产仓库。当然，在需要时，人们仍然可以从生产仓库中撤出。

随着人们积累经验，他们应该轮换担任网守的角色，以获取他们似乎缺乏的更深刻的理解或关心。

通常，请使用Occam的Razor：整个回购结构应尽可能简单以完成其工作。

另请参阅肖恩的评论。

开发人员可能根本无法很好地获得DVCS，但我认为您进行的工作太多了，开发人员无法随时跟踪他们的工作情况。他们忘记了应该在哪个分支工作，并且他们的更改最终在错误的位置进行。

我建议您在每个人都定期在所有这些分支中工作这一事实上遇到问题。

@ andy256建议为产品创建一个单独的存储库肯定会有所帮助，但是您可能需要考虑以不同的方式打包工作，或者安排一些事情，以使开发人员在给定的一周内不会在多个分支上工作。

看来您已经确定了我的主要错误熊之一。大多数源代码控制工具就是源代码控制工具。它们允许一堆开发人员在同一源目录上工作，进行更改并处理冲突。沿途有一些粗糙的地方，但是cvs，subversion，git，mercury等等都可以实现。

然后，当需要稳定代码发布时，可以进行下一步，并引入分支。这是工具开始使开发人员失败的地方。这些工具能够进行分支，甚至可以识别分支分支之后在分支上产生的变更集，但这不是您现在要面对的问题。

这些工具的确无法选择需要将哪些更改复制到其他分支以及何时需要进行更改。Git-flow尝试通过创建分支策略来解决此问题，这意味着分支合并时，其所有更改都将合并，然后要求程序员对何时以及合并哪些分支做出明智的选择。

在所有开发人员都在一个具有单个发布线程的项目上的单一存储库中，git flow解决了这个问题，但是对于许多公司而言，生存并不那么简单。

在复杂的环境中，您有多个团队负责整个解决方案的不同方面，并向其他团队执行内部发布。git-flow只是不能解决这种问题。

我看到这项工作的唯一方法是，每个团队是否负责定义其发布，并控制其依赖项何时更改。仅仅因为A团队发布了1.3版本，B团队选择后B团队才开始使用A的1.3版本。

实际上，一组开发人员定义了需要移动的更改组，接收更改的开发人员定义了何时接收更改组。

我所见过的唯一真正能够实现这一目标的源代码控制工具是Accurev －即使那样，您的大多数开发人员也会对此抱怨不已，因为GUI对于他们来说太混乱了，并且它的行为不像Subversion。