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