请教大家这样的项目应该要怎么做 git 管理

[houshengzi]

前提：手头上准备有一个项目 project 要开发，目前规划是会开发出一个基础版本，然后这版本上线后，基于该版本会按照不同的客户需求有一些差异不大的定制化修改，可能就会出现 project-A 、project-B 甚至是 C/D/E....等多个版本。

团队考虑了两种版本管理方式：

1. 分支模式。 除了常见的 main/dev/release ，对于定制化的就从 main 拉出对应分支 project-A ... Z ，如果 A 有修改则拉出 feature 进行开发，开发测试完毕合回 project-A 里。 如果 main 有通用更新则按照情况从 main 合到 project-A ... Z ，同理如果 project-A 的一些功能验证过后按需也可以合回到 main 。

2. fork 模式。 基础版本正常开发迭代，有定制的需要时则从基础版本 fork 出一个 project-A ，它可以方便地随时同步上游仓库的修改，project-A 有被用户验证过后的功能也可以向上游仓库发起 merge 请求合到基础版本中

个人感觉分支模式到时候如果真的出现很多 project-X 分支的时候，有可能分支之间合并就乱了，也会把 git 的记录搞得很花。

另外解决怎么安排测试也是一个大问题

大家对以上两种模式有什么看法或建议？ 或者有更合理的管理模式也可以提出供我们参考

[xiejay97]

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

[vxf]

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

[Belmode]

做过类似的，都是通过 branch 来管理的。

最恶心的是，即使 A 业务分支已经存在的需求，B 业务分支也要，很多时候是无法简单 merge 或者 cherry-pick 的，只能手动挑选合并代码，好多定制的地方都不一样，随着时间发展，不同甲方的要求越多，就相当于一个新项目了，这时候就可以拉新仓库了。

我和你说，这种需求往往都有很多坑，版本一个控制不好，就 G 了。

[houshengzi]

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

[houshengzi]

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

[houshengzi]

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

[houshengzi]

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

[houshengzi]

@pangzipp #11 还没试过这种模式，可以去验证一下。

[houshengzi]

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

[houshengzi]

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

[houshengzi]

@xavierchow #19

@k9990009 #20

@xiejay97 #21

@vxf #22

@Belmode #23

感谢以上几位。大家的核心思路都差不多的，就不逐一回复了。收集好大家意见会拿去和团队成员继续讨论的

[newaccount]

@houshengzi #25 这种情况 cherry-pick 一下就好了吧，没必要非得 merge 把线连上

[zhuisui]

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

[0xD800]

有相同需求。
简单说下我的方式，希望对你有帮助。
1. 创建一个基础 git 工程
2. 衍生工程基于基础工程创建

衍生工程新增一个名为 upstream （基础工程）的 remote origin ，如果涉及基础工程的变更，需要把变更推送到 upstream ，其他工程可以更新本地 upstream 代码，然后基于 dev/release 分支创建一个更新分支，再 cherry-pick 最新的 commit ，然后合并到 dev/release 。

[2han9wen71an]

我们是主产品一个仓库，每个客户有一个组织，定制化业务都是单独的仓库。

但是我们系统是插件化的，用户提出的需求如果有共性，我们会考虑合并到主产品中，否则都是以插件加载到平台中

[HtPM]

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

[liujavamail]

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

[dxddd]

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

[2han9wen71an]

@liujavamail 我们插件化使用的 OSGI 技术，可以动态加载插件