Branch 基于TFS的成熟分支策略

我的团队最终将从SourceSafe转移到TFS 2010，我们正在努力制定我们的战略

我们需要能够将错误修复放在下一个服务版本中，同时仍在处理当前的服务版本。基本上，在某个时刻，我们将停止在当前版本中进行bug修复（除了一些关键版本），并在一两周内试用该版本。在这段时间里，我们仍然希望修复bug，所以我们将它们放到下一个服务版本中。这与将在下一个主要版本中进行的开发是分开的

我们喜欢成熟的分支策略的外观，它包括从main分支出一个服务发布分支，从服务发布分支出一个热修复分支，从热修复分支出一个发布分支。然后我们要做的是让发布分支成为我们正在试验的分支，并且仍然能够向服务发布分支添加bug修复。然后，当我们完成试点并完成最后的关键更改后，我们通过热修复和服务发布分支将发布分支合并回main，然后从服务发布分支创建一个新的热修复和发布分支，这将是我们的下一个服务发布

我遇到的最大问题是，我希望进入main的任何东西都能得到充分的测试。发布分支将被删除，但当我们将其合并回主分支时，它将接收我们已签入热修复程序和服务发布分支的任何更改。目前还没有对这些更改进行测试

为了解决这个问题，我们计划让开发人员在服务发布分支中搁置他们的更改，直到该版本合并到主版本中。这对我来说似乎不是个好主意，但我想不出还有什么别的办法来处理这个问题

---

是否有其他人必须做类似的事情，并有更好的方法来处理此问题？

您可以在主分支上切换到

门控签入

，以确保所有代码都已编译，所有自动测试用例都已运行。这将减轻开发人员在测试主分支（自动）的同时手动创建搁置集的负担。这将很好，但是，我们的大多数代码仍然是VB6，没有自动测试。我们所能做的就是在合并到main之前检查它是否编译。