我们正在将一个大型项目从VSS更新到TFS2010，我们需要建立良好的分支/合并策略。我们赞成功能分支，但我不知道我们是否应该只分支每个功能中受影响的子项目/文件（就像我们在VSS中那样），或者应该总是分支整个代码库并依赖于惰性复制和良好的合并（如在git / mercurial中）。
我到目前为止在网上找到的指南讨论了分支策略（按发布，功能等分支），而不是关于哪些文件/子项目应该执行分支。
有没有“正确的方法”来做到这一点？假设我们有这样的设置：
Code
|
|- ModuleA
|- ModuleB
|- ModuleC
|- ModuleD
我们有一个影响ModuleA和ModuleD的功能F.我们会更好地分支代码，或仅仅是ModuleA和ModuleD吗？
答案 0 :(得分：2)
如果您的功能影响整个代码库中使用的内容，请分支整个代码库。您仍然希望在功能分支上运行CI构建，因此您希望所有自动化测试都能像往常一样运行。
即使某项功能仅影响您应用程序的一小部分，您仍然希望能够整体测试该应用程序，以确保您没有引入任何重大更改。
我建议您阅读ALM Rangers' branching/merging guide，您可以从CodePlex下载。
答案 1 :(得分：1)
我在这个主题（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版本执行操作（避免冲突文件版本）。
活动项目：交付生产
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
重现同一个组织......
备注：在我的博客上写了帖子