Git是否具备类似svn:externals的功能？多仓库协作方案咨询

我目前有一个位于SVN中的code目录，结构如下：

/code
├ Dockerfile        # 用于创建包含这些包的CI镜像
├───clitools/       # 其他仓库的命令行工具（如qa make-docs、qa test-package等）
├───doclib/         # 文档创建/收集/构建代码
├───glapi/          # GitLab API相关代码
├───pkgtools/       # 处理标准包结构的代码
├───repolib/        # SVN/Git/Hg通用接口
├───synclib/        # 从多种版本控制系统的仓库拉取代码
├───runners/        # 运行同步/异步/并行任务的代码
└───testpackage/    # 代码检查、分析、测试、构建工具

这些子目录是独立Git仓库中的Python包，由于GitLab不支持svn:externals，它们在SVN中被标记为忽略，目前通过自定义工具一键拉取最新代码。部分包存在相互依赖，跨仓库开发是常见需求。

当前核心问题 #

• 新增全局syncspec功能后，执行qa fetch-global ./syncspec.txt前必须先拉取所有code/*仓库的最新代码，才能重新运行命令
• 新机器初始化时，需先同步所有code/*包并执行pip install -e .安装，才能拉取完整的仓库内容

需求与疑问 #

原本使用SVN时，可通过svn:externals实现code目录提交时同步子包变更，执行svn up code就能拉取所有内容。了解过Git子模块但口碑不佳，想找Git中的简单方案：实现对code仓库执行git clone/pull/push时同步所有子仓库变更——比如修改code/doclib和code/glapi后，执行git push code即可提交两个仓库的变更，无需单独处理上游仓库。同时疑惑是否被SVN的思维局限，目前考虑的方向是将所有包合并到一个大的code仓库，或通过工具将多仓库视为统一单元处理。

方案一：合并为单一Git仓库 #

这是最贴合需求的直接方案：

• 将所有子仓库的代码合并到同一个code仓库，保留各原包子目录的独立结构
• 开发时直接在大仓库内修改所有包，提交、拉取、推送仅需操作这一个仓库，彻底消除跨仓库同步问题
• 优势：操作逻辑简单，完全匹配你熟悉的SVN单目录工作流，无需额外工具维护
• 注意事项：合并前可用git filter-repo将各子仓库的历史迁移到对应目录下；CI/CD流程需调整为针对单仓库内的子目录执行任务

方案二：自定义工具封装多仓库操作 #

若需保留仓库独立性，可基于现有工具扩展封装统一命令：

• 编写脚本（如qa sync-all、qa push-all），在code目录下遍历所有子仓库，自动执行git pull、git push等操作
• 新机器初始化时，脚本可自动克隆所有子仓库并执行pip install -e .
• 针对qa fetch-global的问题，在脚本中先完成所有子仓库的拉取，再自动调用原命令
• 优势：保留各仓库独立维护的灵活性，适合需单独发布部分包的场景
• 注意事项：需要维护自定义脚本，处理冲突等异常情况时仍需逐个仓库操作

关于Git子模块的补充 #

虽然子模块口碑一般，但如果仅需"拉取时同步所有子仓库"，它可以满足基础需求。不过提交时需要额外步骤：先提交子模块的变更，再提交主仓库的子模块引用。如果追求和SVN externals完全一致的提交体验，子模块确实不如合并仓库或自定义工具直接。

内容的提问来源于stack exchange，提问作者thebjorn