Git 多个分支如何正确的共享代码，并且保持分支独有的代码?

[Uzor]

我们的应用场景是这样的:

公司内网版本基于 master 开发， 同时给若干个客户提供定制功能， 比如分支名称为 master_B，masterC... 由于产品还在开发过程中， 所以大部分功能两个分支都是需要的 两个分支又有部分代码不能共享，比如有一些功能只有内部需要使用，另一部分代码只有客户需要 现状： 现在刚从 SVN 迁移到 Git， 目前主要基于 master 开发， 本地开发时使用基于特性 master 的特性分支， 开发完成之后 pull 一下远程 master 分支代码，并且提交到 Gitlab，提 Merge Request。 如果两个都需要就提两个 MR, 但是这样会把 master 的代码带入到 master_B 上去， 并且 master_B 独有的代码也经常可能冲突。

这种场景应该如何正确的使用 Git?

[wiselyv2]

这是项目的代码复用设计的不好，不应该让 git 背锅，难道不是在基础框架上通过插件的方式增加定制功能？

[paranoiagu]

cherry-pick 到 master_B，有冲突就解决，然后再测试一下，肯定有问题，但是大问题应该没有吧。
再说总比人肉处理要好。

[shoaly]

这种客户定制的事情 没办法用分支来处理的, 最后必然导致冲突, 或者所有分支补丁升级也不现实.

正确的方式是将所有客户的定制功能做成模块, 然后制作权限系统, 单个客户设置不同的权限使用各个模块即可.
这样有一天你的 A 客户提出和 B 客户一样的功能的时候, 不是代码级别的 merge 而是 后台给 A 客户开放这个权限即可.

[msg7086]

Rebase 或者 Cherry Pick。
一个主干分支，然后若干个定制分支。

[shoaly]

再补充一句, 如果做不到 上述的分模块, 那么就老老实实每个客户单独分出来一个项目, 用 git 分别管理, 别合成分支了, 分了家的代码, 每次都人肉 Ctrl+C Ctrl+V 过去吧

[dangyuluo]

GIT 不是这样用的。权限和模块的思想很好

[reus]

都有人提到 cherry-pick 了，怎么还那么多废话连篇

[HangoX]

必须要模块化。。不然迟早出事

[frankynwa]

使用 git 建议不要弄个人长期分支。

[leohxj]

为什么不是 fork 两个仓库（定制 A，定制 B ），你基于的都是 内网版本吧。
你在 A, B 仓库下修改代码，只需要 merge 内网版本的 master。

当然楼上说的权限和模块，我觉得更合理。

[Rob007]

master 只做公共需求和缺陷，定制化部分留在个客户分支。
master 做定期内部发布。
定制分支从 master 合并(全量或 cherry-pick 增量)。
定制分支上的定制功能可能回归到 master 作为功能需求。

也可以将所有需求(包括定制化)都在 master 实现，通过开关控制，版本的时候根据客户的配置表控制打开哪些功能开关

这些都和项目管理、需求管理和开发流程相关。SVN 和 GIT 只是个工具。

[wonders2002ok]

@shoaly 正解！

[Cbdy]

git 子模块
git submodule --help

[prasanta]

使用 git flow 规范

[wizardoz]

所有功能并存在代码中，通过配置来定制不同模块。

[ycmchong]

cherry-pick