前提：手头上准备有一个项目 project 要开发，目前规划是会开发出一个基础版本，然后这版本上线后，基于该版本会按照不同的客户需求有一些差异不大的定制化修改，可能就会出现 project-A 、project-B 甚至是 C/D/E....等多个版本。
团队考虑了两种版本管理方式：
-
分支模式。 除了常见的 main/dev/release ，对于定制化的就从 main 拉出对应分支 project-A ... Z ，如果 A 有修改则拉出 feature 进行开发，开发测试完毕合回 project-A 里。 如果 main 有通用更新则按照情况从 main 合到 project-A ... Z ，同理如果 project-A 的一些功能验证过后按需也可以合回到 main 。
-
fork 模式。 基础版本正常开发迭代，有定制的需要时则从基础版本 fork 出一个 project-A ，它可以方便地随时同步上游仓库的修改，project-A 有被用户验证过后的功能也可以向上游仓库发起 merge 请求合到基础版本中
个人感觉分支模式到时候如果真的出现很多 project-X 分支的时候，有可能分支之间合并就乱了，也会把 git 的记录搞得很花。
另外解决怎么安排测试也是一个大问题
大家对以上两种模式有什么看法或建议？ 或者有更合理的管理模式也可以提出供我们参考
23 条回复 • 2024-12-28 19:44:09 +08:00
 |
1
zhuisui 1 天前
对于 git 来说，你这两种模式没区别，都是 branch.
你说 fork 的时候是不是指 github 上的 repo 。这时候这两者的区别在于 repo 层面的管理，包括 org 、member 、permission 什么的。 你这种需求——拆出去、合回来，用 branch 管理是最合适的，设计好各种条件下如何建分支就好了。不要用什么 cherry-pick 甚至多项目。 |
 |
2
newaccount 1 天前
1 分支模式
已经上线运行的东西 客户不给钱，公司没有升级的动力 公司想升级，客户未必愿意冒风险 基于这个理由，project-A 同步 main 这个需求不存在 |
 |
3
dalaoshu25 1 天前
交付给客户的当然是 release 分支，里面可以有一些针对客户的定制，跟主线无关的。
貌似“定制化”也应该是从 release 分支再拉出 feature 乃至 hotfix 分支。这些定制有没有需要合并回主线，另外再评估。 |
 |
4
angryfish 1 天前
从来没做过这种定制化需求的项目，很好奇怎么管理那么多不同公司需求版本的。
|
 |
5
xingheng 1 天前
无脑 fork ，定制需求更新会很低，分开管理最好，分开了也可以合并基础版本的代码，不冲突。
|
 |
6
flyPig9527 1 天前
@angryfish 各种 if 判断
|
|
7
flyPig9527 1 天前
@angryfish 说错了，这种很麻烦，各个分支切换要重新装依赖，同时开发多个定制分支就很蛋疼
|
 |
8
nikenidage1 1 天前
是不是应该考虑做成功能开关？不同的客户，只是哪些功能打开关闭而已
|
 |
9
Jonz 1 天前
我们应该算是分支模式。
我主要负责标准品的开发，也就是 feature 分支开发，然后本迭代完成下发后拉 release 分支。 特单部门的同事接到新的定制需求就会基于标准品最新的 release 分支拉个 release-xxx 需求的分支进行开发和发布。 不过有个前提是我们的特单理论上是不会直接升级到标准品的。遇到特别严重的问题就手动把代码改过去。 |
 |
10
Sainnhepark 1 天前
可以考虑把部分定制化需求用配置文件控制，如果差异确实较大，可以考虑把公共的实现放到一个 common 库，然后构建的时候构建多个版本的程序
|
 |
11
pangzipp 1 天前
有没有可能 main 作为基准。对外提供接口
然后定制好业务去聚合接口呢？ |
 |
12
0x5c0f 1 天前
今天才整理的，你应该需要的是这个
 |
 |
13
bfdh 1 天前
不要拉分支，不同分支会越差越多，最后结果就是不同分支之间的修改完全没法同步/合并。
我现在是所有项目一个分支，每个项目有自己的配置目录，根据配置进行编译。 |
 |
14
hzymyp 1 天前
之前是按照多个分支来管理的，后来发展成了近 30 个分支的树状结构，实在受不了又改成功能开关模式了
|
 |
15
LemonNoCry 1 天前
可以用分支模式，可以用目录来区分
比如 标准版：dev/release/preview 客户 A: A/dev ，A/release ，A/preview 客户 B 以此类推 就是合并会比较繁琐 但是一般情况不会升级，只有客户反馈等等，比如标准版已经加了其他功能，客户 A 的版本还是老版本，没有特别一般不会进行升级， |
 |
16
PolarisY 1 天前 via Android
搜一下 gitflow ，基本是业内共识规范，可以在其基础上客制化。至于你提到的切换问题，可以 clone 多个本地库互不影响呀。
你应该基于权限考虑去设计这个规范。 |
 |
17
HtPM 1 天前
巧了，我们公司目前就是用的你提到的第一种分支模式。有一个 master 分支作为公司的线上发布 Release 版本(作为里程碑)，比如 OEM 厂商 1 需要定制一个功能，就基于 Master 分支新建另一个分支，比如名称取为：master-oem1 。目前已经 144 个分支了。这种模式下暂时也没什么大问题，不过偶尔需要合并大量的代码的时候会有点痛苦，不过基本上问题不大(因为我们是小公司[doge])
|
 |
18
cnnblike 1 天前
搞一个门禁，把所有 master 上的 commit cherry-pick 到定制分支上
|
 |
19
xavierchow 1 天前
2 楼 @newaccount 讲的很对，相信我，一旦定制化以后，你不会有机会 merge 回来了，不同客户的需求下，分支模式并不适合。
建议把基础版本作为一个 git template repo ，需要定开的话，直接 clone 出一个新的 repo 独自演化吧。 |
 |
20
k9990009 1 天前 via Android
现在用的分支模式。客户的代码落后 N 个大版本了，除非不更新。实际上一些好用的功能和优化会，不同分支相互合并。太痛苦了。应该考虑模块化，插件化去做
|
 |
21
xiejay97 15 小时 39 分钟前 via Android
最好不要用分支，会有各种各样的坑，比如包管理器的依赖不一样，而且业务代码本身逻辑是连续的，基本上定制就很难再合并，只会合并 fix 类的 commit 。
把功能做成插件这个路子实践下来只会让代码变成💩山。 当初拿什么版本中标的就拿什么版本去 clone 开发。 |
 |
22
vxf 10 小时 6 分钟前
通用的东西抽出来一个 base repo
|
 |
23
Belmode 7 小时 56 分钟前
做过类似的，都是通过 branch 来管理的。
最恶心的是，即使 A 业务分支已经存在的需求，B 业务分支也要，很多时候是无法简单 merge 或者 cherry-pick 的，只能手动挑选合并代码，好多定制的地方都不一样，随着时间发展，不同甲方的要求越多，就相当于一个新项目了，这时候就可以拉新仓库了。 我和你说，这种需求往往都有很多坑，版本一个控制不好，就 G 了。 |
Select Language