从一个在配置管理的沼泽和战壕中度过了几十年的人那里得到它：
不要使用分支
对不起，我想警告你不要去那里。甚至不想去那里。分支意味着处理分支，它永远不会发生。它变得越来越难以维护，并且开始被忽视。让我们看看两种不同的策略：
每个客户的分支
哦，听起来很简单。我将创建一个基本项目，并在不同的客户分支上标记客户之间的差异。如果所有客户都有变化，我会把它放在基础分支上，然后将它合并到所有不同的客户分支上。还有什么比这更简单的？
我见过很多公司因为这种策略而倒闭。他们决定为客户创建自定义代码，因此他们为该客户分支然后，第二个客户需要自定义代码，他们为此分支。然后是第三个。现在，似乎客户端 #3 也需要对客户端 #1 进行更改。好吧，我们将从客户端 #1 合并到客户端 #3。等等，客户#2 也需要改变。好的，我们也将它合并到客户端 #2。
但是，这个功能现在在您的所有客户端中，但不是您的基本代码。您的基本代码与您的客户所拥有的完全不同步。总有一天，您会将这些更改添加到该基本代码中并对其进行更新，但您永远不会这样做。相反，它会成为一个溃烂的提醒，你已经搞砸了。
每五年，您应该获取源代码，将其放入粉碎机并重新开始。那是因为每五年，整个软件环境都会发生如此大的变化，以至于您的遗留代码成为您拖来走去的枷锁。如果您有一个项目，那么开始一个新项目也不会太糟糕。但是，您现在有六个客户和六个不同的项目。你不可能有资源把所有东西都放在一起。你已经把自己写进了一个虚拟的角落。
但是，竞争对手会来，他们将拥有最新最好的代码，他们会一个接一个地把您的客户拉走，直到他们全部消失，您的工作也是如此。我一遍又一遍地看到它。您必须不断创新，但如果您到处都有客户特定的代码，那就很难了。
保留核心代码并仅针对特定客户的内容进行分支
听起来很简单，如果您从未编程过的话。开发人员确切地知道这意味着什么：您需要从两个或三个单独的项目和/或分支中签出才能进行开发。其中一些组合会产生难以追踪的整洁而有趣的错误。您的持续构建服务器将为每个可能的组合带来工作机会。被认为是客户特定的代码现在是基础代码，必须移动（尽管这可能永远不会发生）。
最后，根本不可能保持直线。您最终会得到在您的基础中应该是特定于客户端的代码，并且在您的客户端之间传播的基础代码。这与第一个场景非常相似，但您还添加了一个事实，即您的构建系统也是地狱。
那你该怎么办？
- 首先，使用 Maven。我不是 Maven 的忠实粉丝，但它可以做很多事情。
- Maven 会准确告诉您如何布置所有内容。你把你的源代码放在这里，你把你的 JSP 放在这里。没有人可以争论它，因为 Maven 这么说的。你可以不同意，但不能争论。 Maven 会让您将每个 jar 或 war 作为一个单独的子项目，并将其自己的
pom.xml 放入您的项目（其中将有一个 pom.xml 将所有内容联系在一起。这是处理此问题的正确方法。
- Maven 具有处理依赖项的内置方式。这不仅适用于第三方 jar，还适用于您生成的多个项目使用的 jar。创建一个本地 Maven 存储库并使用它。
- 不认识 Maven？学习它。学习它，就好像你的工资取决于它，因为它确实如此。对于 Java 开发人员来说，了解 Maven 每年可能价值约 20,000 美元。是的，了解 Maven 的开发人员可以获得更多报酬——大众捷达和奥迪 A6 的区别。
- 创建统一版本并使用配置记录来确定客户端应该看到的内容。如果客户端 #1 需要功能“A”，客户端 #2 需要功能“B”，则将 A 和 B 都放入代码中，并通过配置记录确定客户端看到的功能。这样做的目的也是让您在编码之前进行思考。检查客户特定的分支并破解非常容易。但是，如果您有十几个客户并且只有一个代码库，您就无法做到这一点。你开始寻找和看到共同点，也许是处理这种情况的更好方法。你最终会得到更好的代码。
- 会有客户特定的代码。在这种情况下，为自定义 JSP 屏幕之类的内容创建一个目录。尽量减少这种情况，并使用 Perl 或 Python 脚本来帮助构建客户端特定的布局。事实上，使用单个集中式脚本，并提出一个配置方案来处理构建客户端差异。这样可以更轻松地查看差异。
- 为所有客户端制作一个版本，并设置您的服务器，这样客户端特定的配置不会被新版本覆盖。这使得发布更容易，更不容易出错。
90% 的编码都在初始设计中。其余 90% 正在维护中。分支创建更多维护，并鼓励您不必担心整体设计。非必要不要分支。