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

Question

我们正在将一个大型项目从VSS更新到TFS2010，我们需要建立良好的分支/合并策略。我们赞成功能分支，但我不知道我们是否应该只分支每个功能中受影响的子项目/文件（就像我们在VSS中那样），或者应该总是分支整个代码库并依赖于惰性复制和良好的合并（如在git / mercurial中）。

我到目前为止在网上找到的指南讨论了分支策略（按发布，功能等分支），而不是关于哪些文件/子项目应该执行分支。

有没有“正确的方法”来做到这一点？假设我们有这样的设置：

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

我们有一个影响ModuleA和ModuleD的功能F.我们会更好地分支代码，或仅仅是ModuleA和ModuleD吗？

Answer 1

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

即使某项功能仅影响您应用程序的一小部分，您仍然希望能够整体测试该应用程序，以确保您没有引入任何重大更改。

我建议您阅读ALM Rangers' branching/merging guide，您可以从CodePlex下载。

Answer 2

我在这个主题（Techdays，视频等）上阅读很多，在我的项目中应用此策略，建议作为最佳实践。

  

实施需要执行以下任务：

1。创建一个截断的开发，trunk读取XYZ

注意：开发不是直接在主干上，而是关于一个名为Service Pack分支的女孩。

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

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

活动项目：第一次迭代结束（开发团队认为开发已经完成）。

3。从Service Pack 1.YZ创建一个新的子分支Fix命名为1.0.Z。

注意：此分支包含在交付目标功能后专门用于未来错误修复的所有开发。

4。从Fix 1.0.Z创建。一个新的子分支发布名称为1.0.0。

注意：

• 此分支将保持为只读。

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

• 这个分支是我们交付的图片。

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

• 如果需要，它允许对Rollback版本执行操作（避免冲突文件版本）。

活动项目：交付生产

1. 在生产环境中提供1.0.0版本分支。

6。将Service Pack 1.Y.Z合并到X.Y.Z trunk

注意：此时所有分支都处于相同的进化水平。

事件项目：版本1.0.0上发生错误

7。虫子的处理可以通过两种方式完成：

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

• 创建新分支版本1.0.1

• 发布分支版本1.0.1

• 将Fix 1.0.Z合并到Service Pack 1.Y.Z。

• 合并Service Pack 1.Y.Z.行李箱X.Y.Z。

  注意：您可以多次迭代：1.0,1,1.0.2,1.0.3等。

■如果确定版本稳定，我们决定修复新交付的错误。 - 从Service Pack 1.Y.Z创建。修复一个新的子分支1.1.Z

• 对Fix branch 1.1.Z

进行更正

• 从Fix 1.1.Z创建。一个新的子分支发布名称为1.1.0。

• 提供1.1.0分支

  活动项目：一个重要的新功能

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

重现同一个组织......

备注：在我的博客上写了帖子