多依赖Git仓库管理求助：符号链接失效后合并仓库的疑问

API 探路者

2026-6-16

多Git仓库合并方案及风险说明

合并方法（保留历史版本）

如果需要保留各仓库的提交历史，推荐用git subtree工具完成整合，步骤如下：

选择其中一个仓库作为主仓库（比如选某个嵌入式项目仓库，或新建空仓库），进入该仓库目录：
```
cd path/to/main-repo
git init  # 新建仓库时执行此命令
```

将其他仓库作为远程仓库添加到主仓库：

# 添加共享仓库
git remote add shared ../jaza_embedded
# 添加其他项目仓库，示例为proj1
git remote add proj1 ../proj1-repo

将远程仓库的代码合并到主仓库的指定子目录：

# 把共享仓库的main分支合并到主仓库的shared子目录
git subtree add --prefix shared shared main
# 把proj1仓库的main分支合并到主仓库的proj1子目录
git subtree add --prefix proj1 proj1 main

如果不需要保留历史，直接创建新仓库，将所有仓库的文件复制到对应子目录后提交即可，但不推荐这种方式——嵌入式项目的历史提交对问题排查、版本回溯至关重要。

仓库体积膨胀：7个仓库的提交历史全部整合后，仓库体积会显著增大，克隆、拉取速度变慢，占用更多本地存储。
分支管理混乱：原本各项目独立的分支体系被合并到同一仓库，需要额外的分支命名规则（比如proj1-feature/xxx、shared-fix/xxx）区分不同项目的修改，否则易出现分支交叉污染。
编译配置需全面调整：原本各项目通过符号链接引用共享库，合并后共享库位于子目录，需要修改所有项目的编译脚本（Makefile、CMakeLists.txt等），调整头文件包含路径、链接库路径，易出现路径错误导致编译失败。
误操作风险提升：在同一仓库操作时，可能误修改其他项目的文件，或在主分支上提交单个项目的修改，影响其他项目的稳定性。
CI/CD流程重构成本高：原本各项目独立的CI/CD流水线需要重新配置，要实现“仅当某项目目录下的文件变更时触发对应构建”的逻辑，增加了CI配置的复杂度。
权限控制失效：如果原本不同项目有不同的人员权限限制，合并后无法单独针对某个项目目录设置权限，除非依赖Git平台的分支保护、目录级权限（部分平台支持），但配置成本较高。

如果合并仓库只是为了解决VS Code Git Graph的问题，可以尝试检查Git Graph扩展的设置，看是否有“允许添加工作区外仓库”的选项；或者将所有仓库的目录添加到VS Code的工作区文件（.code-workspace）中，无需合并也能在Source Control中统一管理。

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