在TFS中分支-像在git中那样分支整个代码库，还是只分支受影响的子项目？

我们正在将一个大型项目从VSS更新为TFS2010，我们需要建立良好的分支/合并策略。我们支持功能分支，但我不知道我们是应该只分支每个功能中受影响的子项目/文件（就像我们在VSS中所做的那样），还是应该始终分支整个代码库，并依靠延迟复制和良好的合并（就像在git/mercurial中）

到目前为止，我在网上找到的指南讨论了分支策略（按版本、功能等进行分支），但没有讨论应该在哪些文件/子项目上执行分支

有“正确的方法”吗？假设我们有这样的设置：

Code
|
|- ModuleA
|- ModuleB
|- ModuleC
|- ModuleD

---

我们有一个影响ModuleA和ModuleD的特性F。我们最好是分支代码，还是只模块化和模块化？

我读了很多关于这个主题的文章（Techdays、视频等），在我的项目中应用这个策略，这是推荐的最佳实践

实施需要执行以下任务：

一,。创建截断的开发，主干读取XYZ

注意：发展不是直接在主干上，而是关于一个叫Service Pack branch的女孩

二,。从主干创建一个新的子分支服务包，语言1.YZ

注意：此分支将承载第一个专用开发功能

事件项目：第一次迭代的结束（开发团队认为开发已经完成）

三,。从Service Pack 1.YZ创建一个名为1.0.Z的新子分支修复程序

注意：这个分支包含了在目标特性交付之后，专门用于未来bug修复的所有开发

四,。从Fix 1.0.Z创建。命名为1.0.0的新子分支发行版

注:

• 此分支将保持只读

• 此分支是在生产环境中部署的唯一分支

• 这家分店是我们送货的照片

• 它允许您绘制不同的交付

• 如果需要，它允许在回滚版本上执行操作（避免文件版本冲突）

活动项目：生产交付

在生产环境上交付版本1.0.0分支

六,。将Service Pack 1.Y.Z合并到X.Y.Z中继

注意：在这一点上，所有分支都处于相同的进化水平

事件项目：1.0.0版出现错误

七,。bug的处理可以通过两种方式完成：

■ 如果确定版本不稳定 携带补丁修复分支1.0.Z

• 创建新的分支版本1.0.1

• 交付分支版本1.0.1

• 将修复程序1.0.Z合并到Service Pack 1.Y.Z

• 合并服务包1.Y.Z。到X.Y.Z.主干
  注意：您可以多次迭代：1.0、1、1.0.2、1.0.3等

■ 如果确定版本是稳定的，并且我们决定在新的交付中修复bug。 -从Service Pack 1.Y.Z创建。修复新的子分支1.1.Z

• 对固定分支1.1.Z进行更正

• 从fix1.1.Z创建。命名为1.1.0的新子分支发行版

• 交付1.1.0分支
  事件项目：一个重要的新特性出现了

八,。从主干创建一个新的子分支服务包，语言2.YZ

复制同一组织

---

备注：在我的博客上，我写了一篇文章

，如果你的特性影响了整个代码库中使用的某些东西，请将整个代码库分支。您仍然希望在功能分支上运行CI构建，因此您希望所有自动化测试都像往常一样运行

即使某个特性只影响应用程序的一小部分，您仍然希望能够对整个应用程序进行测试，以确保没有引入任何破坏性的更改

---

我建议您阅读，您可以从CodePlex下载。

对分支整个代码库有任何惩罚吗。。。is像SVN/Git一样智能，只复制实际更改的文件？在我看来，如果这不是性能问题的话，这是非常可取的。是的，它的行为类似于SVN和Git。树枝又便宜又快。