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

Question

我目前有许多团队项目都由 TFS 愉快地管理。

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

例如 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 分支中的生产代码。现在，一半的团队在分支上稳定产品，一半的团队继续在当前分支上做新的（有风险的）事情。
• PROD 1.0 分支已准备好并在生产中交付。该分支保持完整，为交付的版本提供维护和支持。对 PROD 1.0 分支进行修复并合并到 CURRENT 分支中。
• 项目接近另一个里程碑或版本。创建一个新分支，用于稳定 PROD 2.0 分支中的生产代码。使用与前面描述的相同的机制。

使用这种每个版本一个分支的策略，每个发布和维护的版本总是有一个分支，其中可以轻松地在版本和主流当前开发线之间向前和向后传播修复。

考虑到这一点，我们使用 TFS 团队项目来发布某个产品的多个版本。这限制了创建和维护项目空间的开销。

Answer 2

简而言之...去分支！

看来您的版本之间的代码非常相似，您只需简单地分支新版本就可以了。

一般来说，如果您具有以下一个或多个条件，则更改为新的团队项目是有意义的：

• 全新的需求范围和/或不同的工作项类型、
• 完全不同的技术，换句话说，您已经从根本上改变了设计和设计。合并损失大于收益
• 需要存储文档和数据。另一个 SharePoint 站点中的其他令牌
• 不同的开发方法 - 流程模板
• 双方工作的不同团队，可能希望限制用户查看 v1 或 v2
• 计划在完全不同的发布周期中发布这两种产品
• 需要完全独立的报告

阅读您的帖子 我不认识到创建新团队项目后需要继续 - 当然我可能是错的。

如果您决定使用分支变体，您可以从令人印象深刻的 Visual Studio TFS 分支指南 2010 中受益匪浅，关于如何塑造代码库的结构。