Team Foundation Server 2010 - 分支还是不分支？

Question

我目前有很多团队项目都由TFS乐意管理。

我有一个项目，一个Windows应用程序，当前正在使用中，在我将代码库移植到TFS之前，我们手动用于维护生产构建和使用脚本复制/合并文件的新开发构建。

e.g。 App1 v1.x - 生产和 App1 v2.0正在开发中。

在TFS之前，我们手动“合并”到从开发构建到生产构建的错误修复 - 所以v1.x中适用的错误修复也在v2中得到修复。

在这种特殊情况下，v2是完全不同的，重新考虑了ui等。我的问题是将此场景移植到TFS的最佳方法是什么。

我认为有两种选择：

1. 创建一个新的团队项目并继续手动“合并”适用 代码文件。

2. 从当前项目v1创建一个品牌，并在VS中逐个替换/覆盖项目，以便源控件可以将更改管理回主团队项目。 V2也有一些额外的类库 - 如果这有所不同。

Answer 1

通常，这是我们用于进行分支和合并的策略：

• 项目开始。所有团队成员都在单个CURRENT分支中处理1.0版本。
• 项目接近里程碑或发布。创建一个分支，用于稳定PROD 1.0分支中的生产代码。现在，团队的一半稳定了分支机构的产品，一半的团队继续在CURRENT分支上做新的（有风险的）东西。
• PROD 1.0分支已准备就绪并已投入生产。分支机构保持不变，以便为交付的版本提供维护和支持。修复在PROD 1.0分支上进行，并合并到CURRENT分支。
• 项目接近另一个里程碑或发布。创建一个新分支，用于稳定PROD 2.0分支中的生产代码。如前所述使用相同的机制。

使用这种每次发布分支策略，您每个发行版本都有一个分支，并且需要维护版本，在这些版本中，修补程序可以在版本和主流CURRENT开发线之间轻松地向前和向后传播。

在这方面，我们使用TFS团队项目来处理某个产品的多个版本。这限制了创建和维护项目空间的开销。

Answer 2

简而言之......分支！

似乎您的版本之间的代码非常类似，只需简单地分支您的新版本即可。

一般情况下，如果您有以下一项或多项内容，则更改为新的团队项目是有意义的：

• 一个全新的要求和/或不同的工作项类型
• 完全不同的技术，换句话说，你已经从根本上改变了设计和设计。合并比损失更多是损失
• 需要存储文档＆amp;其他SharePoint站点中的其他令牌
• 不同的开发方法 - 流程模板
• 双方工作的不同团队，可能希望限制用户查看v1或v2
• 计划以完全不同的发布周期发布这两种产品
• 需要完全分开的报告

阅读你的帖子我不认识创建一个新的团队项目后需要去做 - 当然我可能错了。

如果您决定使用分支变体，那么您可以从令人印象深刻的Visual Studio TFS Branching Guide 2010中获益，了解如何塑造代码库的结构。