背景: 一份公共代码,所有项目的基础。 每个项目在公共代码的基础上,增加应用代码。 每个项目需要修改公共代码的某些地方(修改地方不确定,实现回调的成本过高,感觉直接修改更简单些) 代码无权限管理要求
我现在想到两个方法:
大家看到这个需求,倾向哪个方法,或是其他合理的实现?
1
lanmiao 268 天前
submodule
|
2
LongMaoz 268 天前
2. submodule 将公仓库码作为所有项目仓库的子仓库
|
3
amon 268 天前
submodule 用起来很恶心,但是听起来不用 submodule 更恶心,哈哈。
|
5
Helsing 268 天前 via iPhone 1
分支多又不影响,又不是拿来看的
用 Git Flow 模式开发的大团队,每个版本每人开一个 feature 分支,那分支多的不要不要的,这不是很正常,又不会影响协作 |
6
Inn0Vat10n 268 天前
" 每个项目需要修改公共代码的某些地方" 你的意思是,公共代码也有多版本,不同子项目依赖不同版本的公共代码?
|
7
darksword21 268 天前
如果是 go 可以放在同一个 workspace 下
例如 /workspace/project-a /workspace/project-b /workspace/pkg |
8
jasonlamvt 268 天前
submodule ,我现在公司的 node 项目非常恶心,只能用 submodule 来引入一些后实现的公共库,你可以结合 ci 来实现其他项目的更新
|
9
lrh3321 267 天前
subtree
|
10
pxiphx891 267 天前
不能把公共部分打成二方包吗
|
11
ikas 267 天前
参考 aosp 源码管理.
我们是自己写了一个简化的脚本,加上一个精简的项目配置文件 manifest.xml manifest.xml 包含了每个模块/项目的分支信息.. |
12
smdbh OP @Inn0Vat10n 公共代码主要是 sdk 和硬件相关,实际不同项目配置会有修改,就要改源码。只是改源码配置和相关代码比较快,自己再封装独立比较花时间
|
13
m1nm13 267 天前
还是公共代码作为 submodule,至于要修改公共代码的部分,说明这个公共代码不那么公共,继续提取公共部分,差异部分抽象出接口由项目单独实现
|
14
realJamespond 266 天前
公共库用 rsync ,其它就是正常 git 库
|
15
uliah 266 天前 1
如果 #13 做不到 , 又不想用 submodule , 可以尝试分支管理来解决:
main 主线 , 不打 TAG stable/1.0 标品,TAG 1.0.x custom/1.0-project1.x 项目分支,TAG 1.0-project.x stable/1.1 标品,TAG 1.1.x custom/1.1-project2.x 项目分支,TAG 1.1-project.x 需要注意问题: 1 、对分支管理和产品规划要求较高: - 一个 fix 需要合并多个 stable 和 custom - custom 的修改可以作为 feat 合回主线, 并应用到其他项目 ... 2 、每个版本最好有维护时间,不然会多到离谱 3 、不要在敏捷上尝试这种方案 |
16
johnhuangemc2 266 天前 1
公共项目如果足够稳定, 建议做成依赖库供其它项目引入.
如果不够稳定, 各项目需要改动其中的内容, 那独立管理成一个代码仓库项目来管理标准版本, 其它项目从它直接 Copy 到项目中用, 重大修改再手工维护到标准版本仓库中. submodule 虽然兼具版本管理方便引用, 但使用起来坑巨多, 没经过训练还容易把 submodule 的版本给搞乱了. 同时对 ci/cd 工具及各云平台的 ci/cd 功能不友好 |