TFS分支策略针对特定变化所需的建议

Question

寻找一些分支策略来应对我们的开发工作。我们使用的是TFS 2010，它使用了一个基本的两个分支分支场景，分别是三个分支：Dev，Main（其他两个分支的稳定的主分支）和Release。目前Main和Release是相同的，Dev分支正在进行大量的改变。

当我们开始最新的开发项目时，假设我们会遵循我们的正常实践，并将开发分支中的所有工作都收集到一个点，然后开始发布过程。那么和往常一样，事情会发生变化，现在我们只希望在Dev分支中完成一些工作（大约20％的变化），并且希望做一个发布。

我们希望推广的大多数更改都是独立的，但有几个文件需要重新开发，并且只保留我们关心的发布功能。

因此，鉴于我们目前的双分支策略，我们如何协调一些本来应该更多地沿着基于多特征的分支策略的线路进行构建的东西？

这是我们与TFS的第一个大项目，很遗憾，我们不会因变更包括东西多的功能，不使用标签，等养成良好的资源管理

在我脑海中最糟糕的情况会以从Main创建一个新分支，将其称为Feature1，然后必须手动将修改从Dev分支复制到Feature1分支。这是唯一的方式，还是有更有效的东西？

Answer 1

是的，我认为你需要创建一个新的分支。但我不会称之为Feature1。我会开始使用发布分支。

从Main创建Release分支。然后，您将合并（不手动复制）您计划包含在Dev发行版中的所有内容。如果主分支没有更改，则合并不应导致任何冲突。现在您可以在Release分支中开始稳定工作。

工作可以在开发中继续，当发布准备就绪后，您将所有修复从发布到开发以及所有更改合并到主要。

由于您今天不使用标签，我认为您应该锁定发布分支。对于下一个版本，您创建一个新版本分支。 （在开始之前，请务必考虑所有发布分支的良好命名约定）然后，您总是能够回到每个发行版。