这是一个创建于 238 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景： 一份公共代码，所有项目的基础。 每个项目在公共代码的基础上，增加应用代码。 每个项目需要修改公共代码的某些地方(修改地方不确定，实现回调的成本过高，感觉直接修改更简单些) 代码无权限管理要求
我现在想到两个方法：
- 一个大仓库，公共代码是主分支，项目开分支。但感觉项目多了分支太多不简洁。
- 每个项目单独仓库，用 subtree 引入公共代码。感觉缺点是 subtree 本身需要命令行操作， GUI 没有支持。对应公共代码显示不直观（对应公共仓库哪个 tag 啥的）。
大家看到这个需求，倾向哪个方法，或是其他合理的实现？
16 条回复 • 2024-04-01 15:30:18 +08:00
 |
1
lanmiao 238 天前
submodule
|
 |
2
LongMaoz 238 天前
2. submodule 将公仓库码作为所有项目仓库的子仓库
|
 |
3
amon 238 天前
submodule 用起来很恶心，但是听起来不用 submodule 更恶心，哈哈。
|
 |
5
Helsing 238 天前 via iPhone  1
分支多又不影响，又不是拿来看的
用 Git Flow 模式开发的大团队，每个版本每人开一个 feature 分支，那分支多的不要不要的，这不是很正常，又不会影响协作 |
 |
6
Inn0Vat10n 238 天前
" 每个项目需要修改公共代码的某些地方" 你的意思是，公共代码也有多版本，不同子项目依赖不同版本的公共代码？
|
 |
7
darksword21 238 天前
如果是 go 可以放在同一个 workspace 下
例如 /workspace/project-a /workspace/project-b /workspace/pkg |
 |
8
jasonlamvt 237 天前
submodule ，我现在公司的 node 项目非常恶心，只能用 submodule 来引入一些后实现的公共库，你可以结合 ci 来实现其他项目的更新
|
 |
9
lrh3321 237 天前
subtree
|
 |
10
pxiphx891 237 天前
不能把公共部分打成二方包吗
|
 |
11
ikas 237 天前
参考 aosp 源码管理.
我们是自己写了一个简化的脚本,加上一个精简的项目配置文件 manifest.xml manifest.xml 包含了每个模块/项目的分支信息.. |
 |
12
smdbh OP @Inn0Vat10n 公共代码主要是 sdk 和硬件相关，实际不同项目配置会有修改，就要改源码。只是改源码配置和相关代码比较快，自己再封装独立比较花时间
|
 |
13
m1nm13 236 天前
还是公共代码作为 submodule,至于要修改公共代码的部分,说明这个公共代码不那么公共,继续提取公共部分,差异部分抽象出接口由项目单独实现
|
 |
14
realJamespond 236 天前
公共库用 rsync ，其它就是正常 git 库
|
 |
15
uliah 236 天前 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 236 天前 1
公共项目如果足够稳定, 建议做成依赖库供其它项目引入.
如果不够稳定, 各项目需要改动其中的内容, 那独立管理成一个代码仓库项目来管理标准版本, 其它项目从它直接 Copy 到项目中用, 重大修改再手工维护到标准版本仓库中. submodule 虽然兼具版本管理方便引用, 但使用起来坑巨多, 没经过训练还容易把 submodule 的版本给搞乱了. 同时对 ci/cd 工具及各云平台的 ci/cd 功能不友好 |
Select Language