我们的应用场景是这样的：
- 公司内网版本基于 master 开发，同时给客户提供定制功能，比如分支名称为 master_B
- 由于产品还在开发过程中，所以大部分功能两个分支都是需要的
- 两个分支又有部分代码不能共享，比如有一些功能只有内部需要使用，另一部分代码只有客户需要
现状： 现在刚从 SVN 迁移到 Git，目前主要基于 master 开发，本地开发时使用基于特性 master 的特性分支，开发完成之后 pull 一下远程 master 分支代码，并且提交到 Gitlab，提 Merge Request。如果两个都需要就提两个 MR, 但是这样会把 master 的代码带入到 master_B 上去，并且 master_B 独有的代码也经常可能冲突。
这种场景应该如何正确的使用 Git?
如果是我来解决这个问题的话：
- 把两个分支合并成一个，避免新写的代码要在人力管理下合并到两个分支上去。也避免两套代码所带来的额外 CI 等开销。
- 有业务冲突的地方，通过功能开关来解决问题：https://blog.travis-ci.com/2014-03-04-use-feature-flags-to-ship-changes-with-confidence/
当然因为我不清楚具体的业务，这个方案也不一定非常合适。
uzor
回复
这么说吧，由业务需求带来的软件复杂度没法消除，只能尝试管理起来。不同的功能向不同的客户可见，这件事肯定是要在某个层面上解决。要么在代码库层面上做拆分，要么在运行时判断。如果你不想在代码里留十几个开关，而是选择用分支 / 分仓库方案，那么就意味着会有十几个分支 / 仓库需要提交代码。而且每个分支至少要有一个部署实例，每个部署实例都可能需要运维方面的开销。如果你的团队能 handle 得了这些问题，当然也可以。
如果你想找更新颖的，更趋近完美的解决方案，那我实在是帮不上忙了。我自身的经验是在功能开关的应用上尝到过甜头，所以会有这方面的偏好。
不过话又说回来，如果你的业务真的是每个客户都有定制的且不能相容的功能需求，那么你的业务会从 SaaS 方向逐渐向外包方向倾斜。这个事我只能说：但愿你从客户手里拿到的钱能满足得了为了应对这样的业务扩展所带来的复杂度而被迫增加的人力成本（这句话好长）。
功能开关或者插件 (Engine) 方式应该是唯一办法。维护多分支不见得能让工作量和出错几率减少。 你说不希望代码里出现太多这样的开关，要不是代码洁癖，要不是代码的控制不到位。 还有种可能是你们的代码会提交给客户方，怕他们乱搞或者其他潜在问题。那就做成 Engine，他们需要什么功能就给他们那些功能。概念上和功能开关差不了多少。
