对于每个产品,您是否需要单独的源代码控制分支?应该始终在四个产品分支中之一开发共同功能,并稍后合并到其他产品中吗?
典型情况:产品A将在下个月发布,需要核心(共享的)增强1,产品B将在四个月后发布,需要核心(共享的)增强2(需要三个月时间来完成)。
/core/trunk
/product_a/trunk
/core (svn:externals 'core /core/trunk')
/product_b/trunk
/core (svn:externals 'core /core/trunk')
/product_c/trunk
/core (svn:externals 'core /core/trunk')
/product_d/trunk
/core (svn:externals 'core /core/trunk')
<更新0>: 请注意,/product_a/tags/REL-1.0.0 可能使用 /core/tags/REL-1.0.0,而/product_b/tags/REL-1.0.0可能使用 /core/tags/REL-1.1.0。常见功能可以在一个独立的平台分支中开发,每个产品都有自己的分支用于特定于该产品的开发。
这并不是对你问题的直接回答,因为我不能百分之百确定是否有一个“一刀切”的答案可以给出。但是Jeff写了一篇关于分支的优秀博客文章。
这是我读过的关于分支最好的文章之一:面对敏捷开发、极限编程、团队协作和并行发布的分支和合并
我认为我会避免将两个项目的分支(因此也是日程安排)耦合在一起。因此,除了单个分支以外,你正在编辑共同功能并编辑多个产品,也许以下两个选择之一:
1)独立开发共同功能
2)与一个产品共同开发共同功能
在你的代码库中,将分支建立在最高可能的位置。也就是说,它应该包含所有项目、共享模块的代码,以及文档、构建脚本、安装程序等等。为什么呢?因为这样做没有任何坏处!在目前所提到的所有系统(SVN、TFS、Perforce、Git)中,创建分支都非常容易。
在使用“路径空间”分支(TFS、Perforce)的系统中,这种策略尤其重要。否则,在不同人的工作区之间生成一致的完整产品套件构建将成为一个维护噩梦。
一旦你实践了这个策略,你就可以在给定的分支中自由地修改代码库的任意部分。你总是可以进行完整的构建来验证集成问题;在任何一组分支之间合并任何组件的选项始终对你开放。但是,SDLC策略的问题是完全正交的。你可以按特性、团队、发布版本或以上任意组合进行分支;你可以根据自己的喜好定义前向/反向集成标准。每个分支恰好是超集的事实在许多策略中都是有利的,只要你的工具能够胜任,这绝不会成为一个缺点。
选择一种策略是个人问题,这取决于许多因素。其他人已经提出了一些著名的文档来帮助你做决定。我认为Microsoft 的 TFS 指南的最新修订版是最好的之一。
编辑:澄清一下,我的意思是它们应该共享一个开发分支。我建议单独使用生产分支来表示正在生产中的代码,并且如果您定期进行错误修复发布,则使用维护分支。
我们有一个类似的情况。我们有用于记录、数据访问和安全性的公共库,但这些库被用于多个项目。我们所做的是为每个产品创建一个单独的分支集,并使用 SVN externals 来链接到公共库。因此,所有项目都拥有独立的分支,而公共库则在所有项目中维护一个“共享”分支。
这样,我们可以确保所有产品都构建在最新版本的公共库上,同时也能够独立地维护项目。
我们使用git将一系列具有共同基础和大量自定义代码的网站构建为一系列分支。
主分支包含核心代码,而主分支的每个分支都是核心的特定定制。在对核心进行更改时,很容易将它们推送到分支中,同时保持每个自定义版本隔离。
18个网站,7人团队的12个月+项目,目前仍然掌控得很好!