情景：
我们的代码叫 CODE，它在 master 上。我们现在有了 A，B，C 三个客户，我们在这个 CODE 上提供功能。
现在，我们为 A，B，C 分别提供了 b_branch，和 c_branch，A 继续使用 master。
我开发了一个功能，从 master branch 出 feature_1，完成后 PR 回 master。一切正常。
但是，B 和 C 也要用这个功能，B 和 C 的代码早就在自己的分支上走的很远了，feature_1 PR 到 b_branch 有大量的冲突。c_branch 也是一样。
我的问题是：从一开始，我该如何管理这种情况下的开发呢？？我这里不是讨论 git 如何操作，而是想求教，在我们的软件开发中，面对此种局面，如何在开始的时候做好准备。
简单的讲，我们有一套代码，应对各种需求，该如何管理我们的代码？
补： 更形象的讲：A 说，我们在 M 功能上加审核（master），B 说，我们在 M 功能上加字段，但是不要审核，C 说，我们又要审核又要字段。
与其说是版本控制问题，不如说是设计问题。笼统地讲，就是要让设计更加模块化，职责明确，高内聚，低耦合，依赖倒置，可拓展性，可配置性。。。嗯，然后就是一大堆软工名词。当我没说。
如楼上几位的建议，把这些 feature 分离出来。code base 就像一个插线板，用主分支维护。特殊的 feature 就是各种插头，按需插拔。
最佳理论是不要面向客户产生那么多的分支，所有功能都做成独立 gem，或者可以启用的模块。
实际情况是不同客户的需求可能有矛盾，而且完全组件化的成本太高，再没有规模的情况下，几个客户需要，按组件化的方式做完美可能收不回本。
所以，最佳实践是收 3 次费用，在 ABC 分支上单独完成该功能。
痛苦的经历告诉我，除非到了万不得已。不要 branch。如果非要 branch 而且要跟着 master 走。那需要一个 专人 负责维护 branch。这个专人，必须资深靠谱。
恩恩。我更倾向 fork 一个新的 repo，再按照 master - develop - release 去管理。至于差别，就各自存在自己的 repo 上。至于麻烦程度，貌似都麻烦的很。。。
感谢楼上及楼下各位，儿童节快乐。。
git 的 branch 太便宜了，以致于基于实际项目各种不种需求场景进行多 branch 开发。然后头头还想 merge 回来。我后来发现每多一个 branch，就多一份人力维护。branch 远了，再回去对照，头都大了，merge 真是不那么好处理的的，尤其是我经常喜欢重构一下代码，这改改那动动的那种 git 提交。
#8 楼 @qichunren 更加潜在的问题是，已经测试通过的东西，再 merge 到别的 branch 出现冲突，可能还会带来新的错误，到头来还得重新测试。这个很可怕，尤其是即将上线之前。
多 branch 维护考验的是测试的程度。肉测的灾难。