多Git仓库嵌套结构选型：submodules、subtrees还是.gitignore？

一、关于Git Submodules的疑问 #

• 冲突是正常的：Submodules本质是在父仓库里记录子仓库的特定commit哈希，当不同开发者更新子模块到不同commit后，合并父仓库时必然会出现冲突——这是submodules的设计特性，不是bug。
• 频繁变更的分布式环境不适合用submodules：因为要求所有协作方严格同步子模块的版本，每次子模块更新都需要在父仓库提交新的commit哈希，维护成本极高，很容易出现dirty状态或版本不一致的问题。如果你的场景没有严格的版本绑定需求，完全不建议用submodules。

二、.gitignore嵌套仓库的可行性与优化方案 #

• 这是适合你需求的实用方案，虽然不算Git官方主推的“子模块规范方案”，但完全匹配你的核心诉求：版本无严格要求、固定目录结构支持相对链接、可单独检出子仓库。
• 批量克隆的优化方案：
  • 不要硬写克隆脚本，建议维护一个配置文件（比如repo-list.txt），每行记录子仓库的目标路径和Git地址，格式如下：

    docs/module1 git@xxx.com:user/module1.git
    docs/module2 git@xxx.com:user/module2.git
    

  • 写简单的bash脚本读取配置，实现批量克隆、拉取：

    # clone-all.sh
    while read path url; do
      git clone "$url" "$path"
    done < repo-list.txt
    

    # pull-all.sh
    while read path url; do
      cd "$path" && git pull && cd ..
    done < repo-list.txt
    

  • 也可以用Makefile封装命令，更符合开发者习惯：

    clone-all:
        while read path url; do git clone $$url $$path; done < repo-list.txt
    pull-all:
        while read path url; do cd $$path && git pull && cd ..; done < repo-list.txt
    

    用户只需执行make clone-all或make pull-all即可按需操作。

三、关于Git Subtrees的评价 #

Subtrees完全不适合你的场景：它会将子仓库的完整历史合并到父仓库中，导致父仓库体积急剧膨胀，直接违背了你“拆分大仓库”的核心需求。而且subtrees的操作复杂度比submodules更高，维护成本大，直接排除即可。

最终推荐方案 #

优先选择**“.gitignore嵌套独立仓库+配置化批量脚本”**的方案：

• 满足所有需求：拆分仓库、固定目录结构、支持单仓库检出、无版本绑定压力
• 维护成本低，操作灵活，适配你的线性历史、文件不移动的场景

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