阻止开发人员在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，我不确定如何合并视觉线索。 题 我们可以使用什么方法，以软件，项目管理或治理的形式来减少（理想地停止）错误的分支，从而占用我们的时间或弄脏我们已部署的代码？ 对于我认为可能会做出上述贡献的原因的具体评论，将不胜感激，但这不应该限制您的答复。