源代码管理是每个产品都需要的独立分支吗?

我将共享代码保存在它自己的产品文件夹中。然后使用 svn:externals

/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

通用功能可以在单独的平台分支中开发,每个产品都有自己的分支用于特定于产品的开发。

不是对你的问题的直接回答,因为我不是100%确定有一个“一刀切”的答案可以给出。但杰夫写了一篇精彩的文章 blog post around branching .

以下是我读过的关于分支的最好文章之一: Branching and merging in the face of agile development, extreme programming, team collaboration, and parallel releases

我想我希望避免将两个项目的分支(以及因此而产生的日程安排)耦合在一起:因此,不要在一个分支中编辑公共功能并编辑多个产品,而应该是以下两种备选方案之一:

1) 独立于任何产品开发通用功能

• 分支公共功能
• 单元测试
• 将其提交回主线
• 建立it的产品特定分支(主线)并在产品中使用

2) 开发一个产品的通用功能

• 建立产品分支
• 在产品分支中,向公共库以及特定于产品的组件添加新功能
• 单元测试和系统测试,并将其提交回主线
• 在其他产品中使用新提交的通用功能的新主线上创建分支

在树的最高点进行分支。是的 应该 包括所有项目、共享模块的代码,可能还有文档/构建脚本/安装程序等。为什么?为什么不呢?到目前为止提到的所有系统(SVN、TFS、Perforce、git)中的分支都很便宜。

一旦您将其付诸实践,您就可以在给定的分支中随意修改任意多或任意少的代码库。您可以始终进行完整构建以验证集成问题;在任何分支集之间合并任何组件的选项仍对您开放。但问题是 是完全正交的。您可以按功能、团队、版本或以上任意组合进行分支;您可以根据自己的喜好定义正向/反向集成标准。*事实证明,每个分支恰好是一个超集,这在许多策略中都是有利的,只要您的工具能够应对挑战,就永远不会是一个缺点。

*选择一个策略是一个独立的问题,取决于很多因素。其他人建议使用一些著名的文档来帮助您做出决定。我把最新修订的 Microsoft's TFS guidance 和他们中最好的人在一起。

把它们都放在一根树枝上。您希望在开发时知道产品a中的更改是否会破坏产品B。这比当您发现产品B必须重写您的公共代码库的一半时陷入合并混乱要好得多,因为您的其他3个依赖于原样。

我们也有类似的情况。我们有用于日志记录、数据访问和安全性的公共库,但这些库在多个项目中使用。我们要做的是为每个产品创建一组单独的分支,然后使用SVN外部链接到公共库。因此,公共库在所有项目的“共享”分支中维护,而所有项目本身都有独立的分支。

通过这种方式,我们可以确保所有产品都是基于最新版本的公共库构建的,同时项目也能够独立维护。

我们通过将git构建为一系列分支,构建了一系列具有公共基础和大量自定义代码的站点。

18个站点,一个12个月以上的项目,7人的团队,它仍然处于良好的控制之下!