1

1

2

1

1 分支模式
已经上线运行的东西
客户不给钱，公司没有升级的动力
公司想升级，客户未必愿意冒风险
基于这个理由，project-A 同步 main 这个需求不存在

3

1

交付给客户的当然是 release 分支，里面可以有一些针对客户的定制，跟主线无关的。
貌似“定制化”也应该是从 release 分支再拉出 feature 乃至 hotfix 分支。这些定制有没有需要合并回主线，另外再评估。

5

1

无脑 fork ，定制需求更新会很低，分开管理最好，分开了也可以合并基础版本的代码，不冲突。

8

1

是不是应该考虑做成功能开关？不同的客户，只是哪些功能打开关闭而已

9

1

我们应该算是分支模式。
我主要负责标准品的开发，也就是 feature 分支开发，然后本迭代完成下发后拉 release 分支。
特单部门的同事接到新的定制需求就会基于标准品最新的 release 分支拉个 release-xxx 需求的分支进行开发和发布。
不过有个前提是我们的特单理论上是不会直接升级到标准品的。遇到特别严重的问题就手动把代码改过去。

10

1

可以考虑把部分定制化需求用配置文件控制，如果差异确实较大，可以考虑把公共的实现放到一个 common 库，然后构建的时候构建多个版本的程序

11

1

有没有可能 main 作为基准。对外提供接口
然后定制好业务去聚合接口呢？

12

1

今天才整理的，你应该需要的是这个

13

1

不要拉分支，不同分支会越差越多，最后结果就是不同分支之间的修改完全没法同步/合并。
我现在是所有项目一个分支，每个项目有自己的配置目录，根据配置进行编译。

14

1

之前是按照多个分支来管理的，后来发展成了近 30 个分支的树状结构，实在受不了又改成功能开关模式了

15

1

16

1

搜一下 gitflow ，基本是业内共识规范，可以在其基础上客制化。至于你提到的切换问题，可以 clone 多个本地库互不影响呀。
你应该基于权限考虑去设计这个规范。

17

1

巧了，我们公司目前就是用的你提到的第一种分支模式。有一个 master 分支作为公司的线上发布 Release 版本(作为里程碑)，比如 OEM 厂商 1 需要定制一个功能，就基于 Master 分支新建另一个分支，比如名称取为：master-oem1 。目前已经 144 个分支了。这种模式下暂时也没什么大问题，不过偶尔需要合并大量的代码的时候会有点痛苦，不过基本上问题不大(因为我们是小公司[doge])

18

1

搞一个门禁，把所有 master 上的 commit cherry-pick 到定制分支上

19

1

2 楼 @newaccount 讲的很对，相信我，一旦定制化以后，你不会有机会 merge 回来了，不同客户的需求下，分支模式并不适合。
建议把基础版本作为一个 git template repo ，需要定开的话，直接 clone 出一个新的 repo 独自演化吧。

20

1

现在用的分支模式。客户的代码落后 N 个大版本了，除非不更新。实际上一些好用的功能和优化会，不同分支相互合并。太痛苦了。应该考虑模块化，插件化去做

21

1

最好不要用分支，会有各种各样的坑，比如包管理器的依赖不一样，而且业务代码本身逻辑是连续的，基本上定制就很难再合并，只会合并 fix 类的 commit 。
把功能做成插件这个路子实践下来只会让代码变成💩山。
当初拿什么版本中标的就拿什么版本去 clone 开发。

22

1

通用的东西抽出来一个 base repo

23

1

24

@zhuisui #1 是的，用 branch 管理会比较方便，在同一个仓库中操作就行了。果然真正的银弹并不存在

25

@newaccount #2 还真有 project-A 同步回 main 的需求。因为会有一些 feature 在 A 中经过验证了后，会合回到 main 中，再以新功能的形式宣传给其他“潜在”客户

26

@dalaoshu25 # 是，也可以从 release 中拉出定制分支。 文中说 main 是因为我司这里也一直是 main 分支 ≈ release 分支的

27

@nikenidage1 #8 可能有些不是功能开关能完成的。之前项目就遇到过有些排序方式客户 A 要求是时间倒序，客户 B 要求的几个列点击切换排序

29

@0x5c0f #12 感谢。你这个就是 branch 模式了，我们的基础版本也是类似的 git 规范。现在是考虑怎么管理从基础版衍生出的定制化项目

30

@HtPM #17 感觉你们业务也很庞大啊，已经 144 个分支。那你们的整个流程大概是什么样的？有没有从定制分支往回合的情况？

33

再补充一些各类现实情况：
- 什么情况下不能用开关控制：各定制功能客户要求不能将自己分支的源代码或功能泄漏给第三方。
- 什么情况下不适合用开关控制：定制功能基本没有共性，但代码同时存在，存在被互相引用的风险（当然这个可以用 lint 或 review 来控制）
- 多个定制方都需要相同的功能：1. 尽量从一开始设计好 2. 开发时，应从 base 分支创建分支，然后将该分支合并到各定制业务分支上
- 什么情况下不要用分支管理，而是分 repo：业务的技术实现会完全分叉，不管是基础库，还是业务框架，都会变得迥异，那么就没必要使用分支来确保同一个 base 代码了

34

35

36

@houshengzi 有从定制分支往回合并的情况，如果两个分支差异过大，需要多个同事配合合并，谁修改的部分会让谁来合。

37

@2han9wen71an 请问下插件化使用的什么技术？ 我们目前也在考虑选型， 项目是 java SpringBoot 的， 不同客户的需求不一样， 还有增值模块，得按需加载

38

我首先意识到这并不是个 git 问题，而是一个工程化的问题。就是我有一个通用能力，但是也有若干定制能力。会发生如下情况：
1 通用能力需要及时推广至所有客户。
2 定制的功能随时都有可能变成通用功能。
3 定制的功能 A 要 B 不要 C 要但是与 A 不同.....。
4 通用能力 有些客户可能不需要，或者有些客户需要定制。
目前这种方式无解，因为软件费用给压的太低，所以公司上层觉得能够用所谓的“通用”+“定制”节省成本，最终会搞出四不像，降低软件质量。
我能想到比较好的解决方案就是把通用能力以 jar 的形式让别的项目进行依赖。你要是定制就在自己的工程里随便开发，如果有相似的，copy 改。如果用到通用的功能，就把 jar 引入。