我们创建了一个用于SaaS业务的Web应用程序。简单的自定义可以通过CSS覆盖甚至简单的插件来完成。
但是，我们有一些较大的“企业”客户对“企业”的定制需求。这些自定义包括对UI的更改，新屏幕，不同的屏幕流，不同的后端，永远不会进入主应用程序的新功能，未来可能会进入主应用程序的新功能等等。对于应用程序的那些更大的更改，我们为每个客户维护分叉。在分叉中，我们只需要根据需要进行更改。代码库不断发展，我们合并并从主人那里挑选出来，让他们了解主要开发树中发生的重要事情。
它有效，但我们都想知道从长远来看它会有多好。我想知道对于需要高度定制的客户来说，最好的办法是什么。
我看到三个选项。
极端模块化
这就是atom editor所做的事情。原子中的几乎所有内容都是通过插件和定义良好的接口完成的。
这样做的好处是可以非常孤立地进行自定义。您不需要大叉，而是需要分叉多个较小的子组件，然后通过不同的package.json将它们组合在一起。
这带来了复杂性的缺点。特别是当涉及到UI的东西时，你需要有良好的接口和良好的钩子来构建。我想知道Atom是否适用，适用于任何复杂的用户界面。毕竟，Github不会面临为不同客户定制维护大量不同版本原子的挑战。他们真的会处于更好的位置吗？最后，它可能归结为保持大量的叉子而不仅仅是几个叉子。
Git branches
这就是我们今天所做的。分支，变基，合并，樱桃选择只是让Git做咕噜咕噜的工作，为不要分歧的事情祈祷。
功能标记
我对此很不满。从GitHub到FlickR的许多公司都广泛使用功能标志。 asana also mentioned他们使用它们仅向一部分客户推出功能。从理论上讲，如果我们可以隐藏功能标志背后的所有自定义设置并保持和平并与一个公共代码库协调一致，那么这听起来相当不错。我们甚至可以确保从最终编译中删除未使用的功能。这也是EmberJS所做的。
但是others warn这些特征标志从长远来看对于可维护性来说确实非常糟糕，并且应该仅用作时间工具，直到该特征最终证明是稳定的。如果我们使用功能标志来隐藏自定义，我们将不得不长时间维护它们。
你会如何解决这个问题？