寻找一些针对我们的开发工作的情况的分支策略。我们正在使用TFS 2010并使用具有三个分支的基本两个分支分支场景：Dev，Main（这是其他两个分支的稳定主分支）和Release。目前Main和Release是相同的，Dev分支正在进行很多更改。
当我们开始最新的开发项目时，我们假设我们将遵循我们的常规做法，并将Dev分支中完成的所有操作都提升到一定程度，然后开始发布过程。嗯，像往常一样，事情发生了变化，现在我们只想采取在Dev分支中完成的一些工作（大约20％的变化），并希望对此进行释放。
我们希望推广的大多数更改都是独立的，但是有一些文件需要重复，并且只保留我们关心的版本功能。
因此，鉴于我们目前的双分支策略，我们如何根据基于多特征的分支策略来协调应该最初构建的内容？
这是我们第一个使用TFS的大项目，不幸的是，我们没有通过让变更集包含多个功能，不使用标签等来实现良好的源代码管理。
在我看来，最糟糕的情况是从Main创建一个新分支，称之为Feature1，然后必须手动将更改从Dev分支复制到Feature1分支。这是唯一的方式还是有更高效的方法？
答案 0 :(得分：0)
是的，我认为您需要创建一个新分支。但我不会称之为Feature1。我会开始使用Release分支。
从Main创建一个Release分支。然后合并（不手动复制）计划包含在Dev版本中的所有内容。如果Main分支没有更改，则合并不应导致任何冲突。现在，您可以在Release分支中开始稳定工作。
可以在Dev中继续工作，当发布准备就绪时，将所有修复程序从Release合并到Dev，并将所有更改合并到Main。
由于您今天不使用标签，我认为您应该锁定Release分支。对于下一个版本，您将创建一个新的Release分支。 （确保在开始之前考虑所有发布分支的良好命名约定）然后，您始终可以返回到每个版本。