我们有一个定制的CMS和许多想要用它构建网站的客户。解决方案结构是这样的：
Libs
- Lib1
- Lib2
- etc
Plugins
- Plugin1
- Plugin2
- etc
MVC Web Project
MVC Web项目包含管理主题，网站布局和资产等等......对于每个客户来说，大部分内容都是相同的 - 只有少数文件会发生变化（主要是与主题相关的东西，配置文件）等等）。如果我们不得不每次都要将项目的副本放入不同的SVN存储库中，那将是一种浪费和维护的噩梦。
我之前从未使用过SVN分支和合并，但我理解这个概念。我想做的事可能有些奇怪......让我解释一下：
我注意到SVN创建了“廉价拷贝”分支 - 所以它不会复制每个文件。我想做这样的事情：
trunk
- code for main project
branches
- Customer1's Project
- Customer2's Project
- then some real dev branches of course
tags
- Version 1 (Generic Demo Project)
- Version 2 (Generic Demo Project)
- etc
我的想法是为每个客户设一个分支，只有少数文件被更改，我希望在发生变化时，很容易将主干中的最新代码合并到每个客户分支。
我猜这不正常，但是它可行吗？有没有人看到任何潜在的问题？
答案 0 :(得分：5)
我的想法是为每个客户设一个分支
我见过这种情况发生在许多公司。
我从未见过一家很高兴他们做过的公司。
考虑一下......当您获得更多客户时会发生什么？维护代码库的复杂性指数级。无论何时进行更改，都必须将其合并多次。每当你修复一个bug，你就必须重新合并并重新测试那么多次。您必须手动跟踪哪些更改已提升到哪些客户分支。并且它将非常， 非常 诱惑/轻松为特定客户执行“快速热修复”，因为他们大声抱怨关于它，然后几乎立即忘记它。
那么测试呢？质量保证是否准备单独重新测试每个分支？因为这正是这导致的地方。 （另一种方法是测试一个分支，合并到另一个分支，并假设它有效。发送与测试的代码库不同的代码库通常不是一个好主意。）
这个混乱很快快。
我注意到SVN创建了“廉价拷贝”分支 - 所以它不会复制每个文件。
在此考虑期间忽略这一事实。磁盘空间并不昂贵。如果为了节省几个字节的磁盘空间而增加维护复杂性，那么在业务层面，您所做出的决策反映出业务及其员工的时间比硬盘驱动器的价值低。对于一个企业来说，这是一个非常糟糕的地方。
每个客户的大部分内容都是相同的 - 只有少数文件会发生变化（主要是与主题相关的内容，配置文件等）
优异。然后，能够管理这一点的一大步是定义完全什么是客户特定的，并将其与不是。在理想的世界中，客户特定的东西（也被认为是特定于环境或特定于部署的）可以在单个配置文件中定义。它可能比这更复杂，但那是你的目标。
您肯定希望避免客户特定的代码。相同的代码库应该满足每个客户，并且应该在该代码库之外定义自定义。这样就可以测试和验证单个代码库。
客户特定的配置可以存储在源代码管理中，通常与代码库并行，并作为构建/部署方案的一部分包含在内。那里不需要分支机构，每个客户都可以在某些自定义文件夹中拥有自己的文件夹。添加一个新客户只需要添加一个新的配置文件夹，最坏的情况是新建一个case语句到构建/部署脚本，以便在准备/打包系统进行运输时从该文件夹中获取。
使用分支（在我看来经常过度使用）偏离代码库，而不是偏离部署目标。 （虽然有些系统确实有像“dev”分支和“prod”分支这样的东西。这些是技术上的部署目标。它真的用作显式快照机制，而不是真正的分支机制。）