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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 2643 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

分支

代码

master

git

16 条回复 • 2017-09-27 09:40:47 +08:00

wiselyv2

2017-09-27 07:37:20 +08:00 via Android

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

paranoiagu

2017-09-27 07:54:17 +08:00 via Android

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

shoaly

2017-09-27 08:17:00 +08:00

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

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

msg7086

2017-09-27 08:17:24 +08:00

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

shoaly

2017-09-27 08:18:41 +08:00

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

dangyuluo

2017-09-27 08:27:18 +08:00

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

reus

2017-09-27 08:41:04 +08:00

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

HangoX

2017-09-27 08:44:48 +08:00 via Android

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

frankynwa

2017-09-27 08:50:17 +08:00

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

leohxj

2017-09-27 08:53:18 +08:00

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

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

Rob007

2017-09-27 09:07:03 +08:00

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

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

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