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

【问题标题】：Team Foundation Server 2010 - To branch or not to branch?Team Foundation Server 2010 - 分支还是不分支？
【发布时间】：2011-09-21 10:01:04
【问题描述】：

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

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

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

在 TFS 之前，我们手动将错误修复从开发版本“合并”到生产版本中 - 因此 v1.x 中适用的错误修复也在 v2 中得到修复。

在这种特殊情况下，v2 完全不同，重构了 ui 等。我的问题是将这种情况移植到 TFS 的最佳方式是什么。

在我看来，我有两个选择：

【问题讨论】：

标签： tfs

【解决方案1】：

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

项目启动。所有团队成员都在单个 CURRENT 分支中使用 1.0 版。
项目接近里程碑或发布。创建一个分支，用于稳定 PROD 1.0 分支中的生产代码。现在，一半的团队在分支上稳定产品，一半的团队继续在 CURRENT 分支上做新的（有风险的）工作。
PROD 1.0 分支已准备好并在生产中交付。分支保持不变，为交付的版本提供维护和支持。在 PROD 1.0 分支上进行了修复并合并到 CURRENT 分支中。
项目接近另一个里程碑或发布。创建一个新分支，用于稳定 PROD 2.0 分支中的生产代码。使用与前面所述相同的机制。

使用这种每次发布一个分支的策略，您始终可以为每个发布和维护的版本创建一个分支，其中可以轻松地在版本和主流 CURRENT 开发线之间向前和向后传播修复。

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

【讨论】：

你们俩的回答都很好。我曾怀疑这是要走的路。实际上，我目前在 TFS 源代码控制中正确组织了生产项目。我有更新的 V2 解决方案不受管理 - 但已经有需要合并回生产 v1.z 版本的更改。
因此，根据您的建议，您建议为 App V1.z 创建一个分支，然后直接从我的非托管 V2 解决方案应用重大且有风险的更改。对于我们在 V1.z 中修复的更改可以合并回 Main？这是要点吗？
这正是使用它的方式。我有以下链接，您可以查看：msdn.microsoft.com/en-us/library/aa730834(v=vs.80).aspx。没关系，它适用于 VS2005，仍然适用。
好链接谢谢。从我可以看到链接中的每个版本的分支示例建议为每个新版本创建一个分支。反过来这样做有什么特别的好处/后果吗？（即生产分支与开发分支）
在实践中，至少对我们来说，我们需要能够为我们的客户维护多个版本。所以我们需要为每个版本都有一个维护分支。
啊，有道理。谢谢你的建议

【解决方案2】：

总之...去分支！

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

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

阅读您的帖子后，我不知道创建新团队项目后有必要去 - 当然我可能错了。

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

【讨论】：