如何处理两个导入同一子模块且需保持子模块版本一致的Git仓库问题

方案1：不改动现有仓库架构，通过自动化降低重复操作成本 #

适合不想调整现有仓库结构的场景：

• 给子模块C仓库配置CI触发规则：当C的主分支有代码合并完成后，自动触发工作流拉取A、B仓库代码，创建专门的C版本升级分支，自动提交子模块指针更新的commit，并创建对应的PR。如果A、B仓库配置了完善的CI测试流程，还可以追加自动触发PR校验、校验通过自动合并的逻辑，全程无需人工介入。
• 本地开发阶段可以编写简单的shell脚本，把「切换A仓库分支→更新子模块C→提交变更→推送→创建PR」「切换B仓库分支→更新子模块C→提交变更→推送→创建PR」这一系列手动操作封装为单次脚本执行，把十几步手动操作简化为1次命令调用。

方案2：调整仓库架构，从根源消除双PR需求 #

2.1 改用Monorepo（单体仓库）架构 #

将A、B、C三个仓库合并到同一个单体仓库中，按目录拆分不同模块：

project-root/
├── module-a/
├── module-b/
└── shared-module-c/

这种架构下修改shared-module-c的代码后，A、B会直接使用最新的C代码，不需要额外提交子模块指针变更，也不需要分别给A、B提交PR，单次提交即可覆盖所有变更，天然保证A、B使用的C版本完全一致。如果需要单独发布A、B的独立版本，可以配合对应技术栈的Monorepo工具链（如Java的Gradle多模块、JS的pnpm workspace、Python的Poetry多项目等）实现单独发布，不影响原有发布流程。

2.2 将C改造为标准依赖包发布 #

如果不想使用Monorepo，可以将C封装为对应技术栈的标准依赖包（如Java的Maven包、Go的Module包、JS的npm包等），每次更新C后发布一个新的版本号。
要保证A、B使用的C版本完全统一，可以给A、B配置公共依赖管理规则：比如Java项目通过父POM统一管理依赖版本，JS项目通过共享的依赖锁文件统一版本，只需要修改一次公共配置就可以同时对A、B生效，不需要分别提交PR调整版本。

方案3：折中聚合仓库方案 #

如果既不想调整现有子模块的独立存储逻辑，也不想改造成依赖包，可以新增一个聚合仓库，将A、B、C都作为聚合仓库的子模块引入：

aggregate-root/
├── repo-a/ (子模块)
├── repo-b/ (子模块)
└── repo-c/ (子模块)

所有开发工作都在聚合仓库下完成，每次修改C之后只需要在聚合仓库提交一次子模块指针变更即可，不需要分别给A、B提PR，天然保证A、B拉取聚合仓库最新代码时拿到的C版本完全一致。

内容的提问来源于stack exchange，提问作者king-network