面对功能定制，我们该怎么管理我们的代码？

小互联网企业面临的选择

互联网企业一开始都只有一份代码，这时候的代码管理也是最容易的，但是随着产品发展方向的不同代码的管理就变得复杂起来。
有的产品只服务于个人，这还好产品完全由公司掌控，开发也只需要在这一份代码上做文章，这时候我们可以任意选择常规的代码管理方式，分支开发主干发布，主干开发分支发布，
甚至在初期，我们都不需要拉分支来减少复杂度；而有的产品是为公司服务的，面对各公司提出的各种需求，这时候就不得不面临选择：

1. 理想状态就是将产品SAAS化，对产品的掌控权还是牢牢掌握在自己手中，我们只需要不断完善产品推出通用的行业解决方案，对开发来说，这种方式也是十分友好。
2. 但是很多时候往往事与愿违，面对各种定制化需求，刚起步的公司很难挡住眼前的利益不去接受，尤其在公司发展初期，这时候产品的发展就不完全由公司掌控了，同一个类型的产品
   将出现很多各不同的版本，对开发来说这也是痛苦的开始，这也是本文将讨论的问题。

开发痛苦的开始

面对定制化需求小公司一般只要给钱就很难拒绝，毕竟都是要恰饭的嘛！不过这时候开发的痛苦也就开始了，面对各种公司的定制我们该怎么去管理我们的代码？究竟是写在一份代码里面呢？还是每接入一个公司就将代码copy一份，在上面完成定制？
我想说这两种方式都只是痛苦的开始。
如果我们把所有的东西都写在一份代码里面，代码将会杂乱不堪，各种if-else语句，好点的开发可能会用各种设计模式来让代码稍微好看点，但是这无疑对开发提出了很高的要求；
如果我们每接入一个公司就copy一份代码，这无疑能降低代码复杂度，不过随着公司接入的越多我们就会陷入麻烦就越大。如：各个版本的代码虽然功能上看起来差不多，但实现有差异;同样的bug我们需要在不同的版本间进行多次修改。
久而久之，公司的开发也会对代码失去热情，听之任之。这也是我们公司的现状，很长一段时间我都在思考，要是我以后面对同样的选择，我要怎么去避免这种尴尬的境地，

或许我们可以这样做

合理的利用版本管理工具

目前常用的代码管理方式是分支开发主干发布，主干开发和分支发布，在这里我就不做过多的说明了。
对于多版本的代码管理我认为可以使用一主干多分支的方式进行管理，主干是核心代码，分支和主干的差异就是定制代码，每当有一个公司接入的时候我们就拉一个新的分支出来，我们在开发的时候主要针对分支进行开发，这时候分支就变成了我们常规意义的主干，核心代码的改动（主要bug修复），和通用功能我们合并到主干。其它分支需要经常去主干拉取代码来更新bug和功能来避免重复的开发工作。如图

实施原则

要想顺利实施，还是需要坚持如下几个原则的：
1.定制涉及到核心代码的修改，要经过认真的评估，尽量通过扩展的方式来修改，或者否决掉
2.能够通用的功能我们尽量设计成通用的
3.分支经常与主干进行同步，避免出现不一致的情况

结论

多版本的代码管理是复杂的，我们应尽量去避免这种复杂性，如果硬是无法避免，希望本文能对大家有所帮助。