使用 git 管理多项目的最佳实践？

[smdbh]

背景： 一份公共代码，所有项目的基础。 每个项目在公共代码的基础上，增加应用代码。 每个项目需要修改公共代码的某些地方(修改地方不确定，实现回调的成本过高，感觉直接修改更简单些) 代码无权限管理要求

我现在想到两个方法：

1. 一个大仓库，公共代码是主分支，项目开分支。但感觉项目多了分支太多不简洁。
2. 每个项目单独仓库，用 subtree 引入公共代码。感觉缺点是 subtree 本身需要命令行操作， GUI 没有支持。对应公共代码显示不直观（对应公共仓库哪个 tag 啥的）。

大家看到这个需求，倾向哪个方法，或是其他合理的实现？

[lanmiao]

submodule

[LongMaoz]

2. submodule 将公仓库码作为所有项目仓库的子仓库

[amon]

submodule 用起来很恶心，但是听起来不用 submodule 更恶心，哈哈。

[smdbh]

@lanmiao submodule 无法修改，所以才换 subtree 的

[Helsing]

分支多又不影响，又不是拿来看的
用 Git Flow 模式开发的大团队，每个版本每人开一个 feature 分支，那分支多的不要不要的，这不是很正常，又不会影响协作

[Inn0Vat10n]

" 每个项目需要修改公共代码的某些地方" 你的意思是，公共代码也有多版本，不同子项目依赖不同版本的公共代码？

[darksword21]

如果是 go 可以放在同一个 workspace 下
例如
/workspace/project-a
/workspace/project-b
/workspace/pkg

[jasonlamvt]

submodule ，我现在公司的 node 项目非常恶心，只能用 submodule 来引入一些后实现的公共库，你可以结合 ci 来实现其他项目的更新

[lrh3321]

subtree

[pxiphx891]

不能把公共部分打成二方包吗

[ikas]

参考 aosp 源码管理.

我们是自己写了一个简化的脚本,加上一个精简的项目配置文件 manifest.xml

manifest.xml 包含了每个模块/项目的分支信息..

[smdbh]

@Inn0Vat10n 公共代码主要是 sdk 和硬件相关，实际不同项目配置会有修改，就要改源码。只是改源码配置和相关代码比较快，自己再封装独立比较花时间

[m1nm13]

还是公共代码作为 submodule,至于要修改公共代码的部分,说明这个公共代码不那么公共,继续提取公共部分,差异部分抽象出接口由项目单独实现

[realJamespond]

公共库用 rsync ，其它就是正常 git 库

[uliah]

如果 #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 、不要在敏捷上尝试这种方案

[johnhuangemc2]

公共项目如果足够稳定, 建议做成依赖库供其它项目引入.
如果不够稳定, 各项目需要改动其中的内容, 那独立管理成一个代码仓库项目来管理标准版本, 其它项目从它直接 Copy 到项目中用, 重大修改再手工维护到标准版本仓库中.
submodule 虽然兼具版本管理方便引用, 但使用起来坑巨多, 没经过训练还容易把 submodule 的版本给搞乱了. 同时对 ci/cd 工具及各云平台的 ci/cd 功能不友好