为不同客户定制的项目采用什么版本控制策略？答案

【问题标题】：What versioning strategy to adopt for a project that is customized for different clients?为不同客户定制的项目采用什么版本控制策略？
【发布时间】：2023-03-12 22:59:01
【问题描述】：

我很好奇其他人会在 Java 项目（Web 应用程序）上应用什么源代码版本控制策略，该项目很可能为多个客户进行定制。

该项目将有一个标准版本，但对于它的一些客户，需要进行一些定制（在不同的分支上）。

通过阅读此主题： What branching strategy should I use during the development/maintenance of a web application? 我猜想“Branch by release”将适合项目标准版本的开发。

现在，在处理客户分支时，对其他客户/标准版本将受益的代码进行了一些改进/错误修复，这意味着对于每个分支都将执行合并和测试，以便保持一切都是最新的。

作为一个约束，对于这个项目，我们坚持使用 CVS 作为源版本控制系统。

对于构建的工件的版本控制，我们将使用 maven（依赖：artifactId、groupId、版本、分类器 - 客户名称 - 以便清楚地区分工件）。

【问题讨论】：

标签： web-applications branch cvs branching-strategy

【解决方案1】：

我建议为每个客户创建一个分支并为每个功能创建一个分支，并让您的主干代表您的“标准版本”。

任何小错误修复都将合并回主干，然后传播到所有分支。新功能也是如此，因为您会将它们合并回主干并终止分支。

您的所有客户分支都将长期存在，您将在那里进行针对客户的自定义并从这些分支中发布。

【讨论】：

假设主干版本在此期间演变为版本 3，并且一位客户的代码与应用程序的版本 1 相同，他决定进行升级。这将在将客户分支升级到版本 3 时产生大量工作。
如果您正在更改主要版本，这通常意味着重大更改。您的客户真的希望对 1.0 版进行的定制成为 3.0 版的一部分吗？这是可行的，但听起来你需要一些更好的销售人员。 :) 顺便说一句，任何使用 CVS 完成的合并都会产生大量的工作。
如果客户为 1.0 版支付了定制费用（另一个仪表板，一些额外的业务工作流程），我认为客户在未来的版本中也希望他的定制功能是正常的。关于 CVS 合并，你是对的。在给定的情况下，您是否有更好的源版本控制策略选择？
我不认为你可以用 CVS 做很多其他事情。使用 git，您可能会将在“客户特定”分支上所做的更改重播到“下一个版本”分支上，具体取决于版本之间所做的更改数量。这就是为什么它取决于您是从 1.0 版迁移到 3.0 版还是从 1.1 版迁移到 1.3 版，分支策略显然会根据情况而有所不同。我会回到我之前所说的：从 1.0 进行的自定义很少会向后兼容到 3.0（见鬼，微软很少这样做）。