如何在多项目间共享Git子模块且避免文件重复？

当前问题背景 #

程序结构如下：

Program /
        |- LibA /
        |       |- SharedLib
        |
        |- LibB /
        |       |- SharedLib
        |
        |- LibC /
        |       |- SharedLib
        |
        |- ... /
        |      |- SharedLib
        |
        |- LibZ /
        |       |- SharedLib
        |
        |- SharedLib

LibA至LibZ均为独立硬件控制库，各自是独立项目/仓库，需供自身Program及外部应用使用。所有Lib都依赖独立仓库的SharedLib接口库。当前用子模块引入的方式存在两个核心问题：

1. 本地会产生大量SharedLib重复副本，占用存储空间；
2. SharedLib更新时，每个Lib仓库都要单独拉取更新，操作繁琐且冗余。

可行优化方案 #

方案1：利用Git alternates共享存储 #

通过Git的alternates机制，让所有Lib仓库共享同一个SharedLib本地副本，彻底避免重复存储。

• 操作步骤：
  1. 在本地单独克隆一份SharedLib仓库，比如放在~/SharedLib路径下；
  2. 进入任意Lib仓库的SharedLib/.git/objects目录，清空该目录内容后，创建info/alternates文件；
  3. 在info/alternates中写入单独克隆的SharedLib仓库objects目录的绝对路径，例如/home/user/SharedLib/.git/objects；
  4. 对所有Lib仓库重复步骤2-3；
  5. SharedLib更新时，只需拉取单独克隆的那份，所有依赖它的Lib仓库会自动同步更新，无需单独拉取。
• 注意：其他开发者拉取仓库后，需手动配置自己本地的alternates路径，适合团队内部约定统一存储路径以降低配置成本。

方案2：用包管理工具替代子模块 #

借助CMake FetchContent、Conan、Vcpkg等包管理工具，将SharedLib作为全局依赖包引入，从根源解决重复存储问题。

• 操作示例（以CMake为例）：
  1. 在SharedLib仓库中配置CMake打包规则，生成可安装的包；
  2. 在每个Lib仓库的CMakeLists.txt中，通过FetchContent_Declare拉取SharedLib指定版本，或用find_package查找本地已安装的SharedLib；
  3. 开发者只需在本地安装一次SharedLib，所有Lib仓库都会复用该本地包，或由包管理工具自动缓存SharedLib副本。
• 优势：
  • 完全消除重复存储，包管理工具自动处理缓存与版本控制；
  • 其他开发者拉取仓库后，仅需执行包管理工具的安装命令即可，配置统一简单；
  • 支持版本锁定，避免不同Lib仓库使用不一致的SharedLib版本。

方案3：使用Git子树替代子模块 #

将SharedLib合并到每个Lib仓库的特定目录，通过子树命令管理更新，既避免重复存储，又简化操作流程。

• 操作步骤：
  1. 在Lib仓库中执行git subtree add --prefix=SharedLib <SharedLib仓库URL> main，将SharedLib合并到指定目录；
  2. SharedLib更新时，在Lib仓库中执行git subtree pull --prefix=SharedLib <SharedLib仓库URL> main拉取更新；
  3. 若需向SharedLib提交代码，可通过git subtree push命令推送。
• 优势：其他开发者拉取仓库后无需额外配置，直接使用；
• 不足：每个Lib仓库会包含SharedLib的代码，仓库体积会增大，版本隔离灵活性略逊于子模块。

方案4：搭建内部依赖仓库 #

针对规模较大的团队，可搭建内部依赖仓库（如GitLab Package Registry、Nexus等），将SharedLib打包后上传，所有Lib仓库通过依赖仓库拉取资源。

• 操作步骤：
  1. 配置SharedLib的CI/CD流程，每次更新自动打包并上传至内部依赖仓库；
  2. 每个Lib仓库通过包管理工具从内部依赖仓库拉取指定版本的SharedLib。
• 优势：
  • 统一管理SharedLib版本，避免版本不一致问题；
  • 开发者无需手动处理SharedLib更新，包管理工具自动同步；
  • 无本地重复存储问题，所有Lib复用同一缓存包。

总结推荐 #

小型团队优先选择方案2（包管理工具），配置简单且能解决核心问题；若团队技术栈统一且可接受少量本地配置，方案1（Git alternates）是低成本选择；大型团队更适合方案4（内部依赖仓库），能更好地管控版本与依赖。

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