我为一家小型单品客户公司工作，该公司正在转型为一家产品，多客户公司。尽管我们只有一个客户，但我们有不同的项目，交付日期不同，但是对于每个项目，我们都能够提供最新的月度发布，我们已将其保存在单独的代码分支中，以防我们'必须为该特定版本提供错误修复。
最近，我们收购了许多新客户并出现了一个新问题：总公司通常会解决（不破坏功能）许多不同客户的具体问题，而不是所有客户都想要所有的变更，而是宁愿喜欢樱桃挑选修复和功能。
您是否有过这种情况的经验，以及如何在不受测试和工作超负荷的情况下处理它（我们的每月发布测试需要大约3天的计算机时间）？和版本控制明智，你如何管理（我猜cvs最终还是要去......）？
答案 0 :(得分：6)
最简单的解决方案是将产品切割成核心产品，并将每个功能切割成插件。这样，每个客户都可以选择他们想要的功能。但即便是这种解决方案也很快就会压倒一家小公司。
实际上，您通常情况更糟：您有一个新功能可以帮助客户A并为客户B打破一些东西（比如说，客户B还没有准备好修改他们的数据库，而且新功能在没有这种变化，实际上这使得新版本无法用于客户B）。如果你很大，你可以简单地忽略客户B。
目前，您确实需要找到一种方法来说服您的客户继续前进。最简单的方法就是赚钱：告诉他们如果能找到适合每个人的解决方案，那么获得量身定制的产品会花多少钱。邀请您的客户，一起建立一个变更列表，让每个人都同意该计划。
另外，你真的必须进行自动单元测试，所以你可以100％确定今天离开房子的产品不可能比你四周前售出的产品更差。
即使有最好的版本控制系统（对我来说，那将是git），如果不能让每个人都朝着同一个方向前进，你就无法解决你所得到的扇出（当然，除了你真的可以将每个客户分成一个插件）。
答案 1 :(得分：4)
我们有一个类似的设置（一个相当专业的）产品和多个（但只有数百个订单）的客户都需要他们自己的宠物功能。
据我所知，您可以选择产品非客户特定的“现成”路线，并且您添加的任何功能都是为了产品的好处（可能是根据客户的要求） ）;或者您沿着定制的咨询路线前进，每个客户都有自己独特的产品版本。
如果您的客户都需要基本相同的产品，那么您应该沿着第一条路线前进，这意味着所有功能都会传递给所有客户。
隐藏功能很容易，维护多个并发版本是一个噩梦！
如果您的客户要求挑选他们的功能，那么可以使用的解决方案是为每个人维护分支，然后非常小心地从您的分支机构复制相关更改。
这意味着您的提交需要尽可能原子化 - 只能解决一个问题 - 而且没有任何更改应直接进入客户分支。但这种方法仍然非常危险。
答案 2 :(得分：1)
在这种情况下可以使用CVS（尽管我建议你看看SVN等其他选项）。
我参与了一些类似的项目。我们所做的是拥有一个Commom分支，系统的核心功能和产品的每个变体的“客户”分支，这样你就可以实现每个客户端的特定功能和错误修正，并仍然在“commom”中使用相同的更改“对产品的所有变化。
这种方法需要大量的配置管理工作（合并和构建），因此您可能希望有一个特定的人来处理这些任务。
编辑：
另外，你应该（如果还没有）有一个bug跟踪系统，你应该在其中记录你正在使用的客户端/分支。
答案 3 :(得分：0)
仅支持head / main trunk，除非有一个分支具有主线中不存在的bug修复/功能。
我知道你说过一些客户不希望这样，但我已经看到了许多分支支持的最终结果。你不希望出现这种情况。这是一场噩梦，将削弱您的开发，产品和测试团队。
不要这样做。
坚定。