这是一个创建于 3128 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们的应用场景是这样的:
公司内网版本基于 master 开发， 同时给若干个客户提供定制功能， 比如分支名称为 master_B，masterC... 由于产品还在开发过程中， 所以大部分功能两个分支都是需要的 两个分支又有部分代码不能共享，比如有一些功能只有内部需要使用，另一部分代码只有客户需要 现状： 现在刚从 SVN 迁移到 Git， 目前主要基于 master 开发， 本地开发时使用基于特性 master 的特性分支， 开发完成之后 pull 一下远程 master 分支代码，并且提交到 Gitlab，提 Merge Request。 如果两个都需要就提两个 MR, 但是这样会把 master 的代码带入到 master_B 上去， 并且 master_B 独有的代码也经常可能冲突。
这种场景应该如何正确的使用 Git?
 | 1 wiselyv2 2017 年 9 月 27 日 via Android 这是项目的代码复用设计的不好，不应该让 git 背锅，难道不是在基础框架上通过插件的方式增加定制功能？ |
 | 2 paranoiagu 2017 年 9 月 27 日 via Android cherry-pick 到 master_B，有冲突就解决，然后再测试一下，肯定有问题，但是大问题应该没有吧。 再说总比人肉处理要好。 |
 | 3 shoaly 2017 年 9 月 27 日  1 这种客户定制的事情 没办法用分支来处理的, 最后必然导致冲突, 或者所有分支补丁升级也不现实. 正确的方式是将所有客户的定制功能做成模块, 然后制作权限系统, 单个客户设置不同的权限使用各个模块即可. 这样有一天你的 A 客户提出和 B 客户一样的功能的时候, 不是代码级别的 merge 而是 后台给 A 客户开放这个权限即可. |
 | 4 msg7086 2017 年 9 月 27 日 Rebase 或者 Cherry Pick。 一个主干分支，然后若干个定制分支。 |
| 5 shoaly 2017 年 9 月 27 日 再补充一句, 如果做不到 上述的分模块, 那么就老老实实每个客户单独分出来一个项目, 用 git 分别管理, 别合成分支了, 分了家的代码, 每次都人肉 Ctrl+C Ctrl+V 过去吧 |
 | 6 dangyuluo 2017 年 9 月 27 日 GIT 不是这样用的。权限和模块的思想很好 |
 | 7 reus 2017 年 9 月 27 日 都有人提到 cherry-pick 了，怎么还那么多废话连篇 |
 | 8 HangoX 2017 年 9 月 27 日 via Android 必须要模块化。。不然迟早出事 |
 | 9 frankynwa 2017 年 9 月 27 日 使用 git 建议不要弄个人长期分支。 |
 | 10 leohxj 2017 年 9 月 27 日 为什么不是 fork 两个仓库（定制 A，定制 B ），你基于的都是 内网版本吧。 你在 A, B 仓库下修改代码，只需要 merge 内网版本的 master。 当然楼上说的权限和模块，我觉得更合理。 |
 | 11 Rob007 2017 年 9 月 27 日 master 只做公共需求和缺陷，定制化部分留在个客户分支。 master 做定期内部发布。 定制分支从 master 合并(全量或 cherry-pick 增量)。 定制分支上的定制功能可能回归到 master 作为功能需求。 也可以将所有需求(包括定制化)都在 master 实现，通过开关控制，版本的时候根据客户的配置表控制打开哪些功能开关 这些都和项目管理、需求管理和开发流程相关。SVN 和 GIT 只是个工具。 |
 | 12 wonders2002ok 2017 年 9 月 27 日 @shoaly 正解！ |
 | 13 Cbdy 2017 年 9 月 27 日 git 子模块 git submodule --help |
 | 14 prasanta 2017 年 9 月 27 日 使用 git flow 规范 |
 | 15 wizardoz 2017 年 9 月 27 日 所有功能并存在代码中，通过配置来定制不同模块。 |
 | 16 ycmchong 2017 年 9 月 27 日 cherry-pick |
Select Language