话说回来，

上篇写了单仓和 Submodule：自己团队的代码往一个仓库里收。要挂别人维护的独立仓库才用 Submodule。老实说，发完就有人来问我：那 Git Subtree 呢？

他是看到网上不少文章说 subtree 是 submodule 的「替代品」，正纠结要不要迁过去。我跟他讲，这俩不是谁替代谁，是两条相反的路。Submodule 是「引」：把别人的仓库挂进来代码还留在外面主仓只记一个引用；Subtree 是「抄」：把外部仓库的代码整个抄进你的仓库。抄完就是普通文件，但留着一条跟上游同步的路。一个是请租客住进来一个是把东西搬进自己家，怎么替代？

先弄清它俩分别是啥

Git Submodule主仓库只记两样——子模块的远程地址和一个固定的 commit 哈希。子模块目录拉下来是完整的独立仓库，有自己的历史、分支、标签。代码并不真的躺在主仓里真身还在它自己的仓库。

Git Subtree一条命令把上游仓库的提交历史接进当前仓库的某个子目录。接进来之后目录就是普通目录：文件在主仓历史里有真实的提交记录。clone 一步到位，日常改完直接 add/commit，没有第二套版本程序。主仓和上游之间靠一次特殊合并提交维系，提交信息里带着git-subtree-dir: libs/util 标记。

还得先澄清一件事：git subtree不是 Git 原生功能。而是 Avery Pennarun 写的一段脚本，被收进 Git 官方源码树（contrib/subtree/)一起分发。大多数环境已经捆绑好，但精简版或自编会报错。需要手动安装git-subtree包。相比之下git submodule是真正内置功能，不会出现“没捆绑”的问题。

关键差异。 一条条过

• 克隆：
  • Submodule： clone 完主仓后还得再拉一次子模块，这一步忘了子目录就是空白。
  • Subtree： 一次git clone 即可得到所有内容，包括子目录。
• 日常改动：
  • Submodule： 需要两步操作：先在子模块里 commit/push，再回到主仓更新引用；漏一步就会出现指针不一致的问题。
  • Subtree： 修改直接对文件操作。接下来 add/commit 即可，无需额外步骤。
• 与上游的来往：
  • Submodule： 拉取更新仅仅是移动指针；如果想把改动推回去，只需在子模块内部 push，即支持双向交互。
  • Subtree： 拉取新提交需要;回推给上游则需拆分成单独分支（)再 push，步骤多且易出错。
• 历史与体积：
  • Submodule： 主仓永远很小，只保存指向子模块提交的引用；其实，历史完全保存在各自独立仓库中。怎么说呢，
  • Subtree： 所有上游提交都会被整合进主仓。如果不使用--squash,主仓体积迅速膨胀，并导致日志杂乱无章。
• 权限管理：
  • Submodule： 每个子模块都是独立存储，可以按个别权限控制。
  • Subtree： 跟随主仓权限。仅能对整个项目设置访问控制，无法细粒度管理某个目录。

Subtree 日常就三条命令

 注意！建议始终带上--squash: 它可以把完整历史压缩为一个提交，从而避免日志爆炸和磁盘占用激增。如果不加，会导致每次拉取都将全部旧 commit 合并进来让你后面难以追踪真正改动。

首次挂入:

# 把外部 repo 的内容整合到 libs/util 目录下并压缩成一个提交
git subtree add --prefix=libs/util  main --squash
}

上游更新时拉取并合并:

# 从远程获取最新 commits 并合并到本地
git subtree pull --prefix=libs/util  main --squash
}

本地改完想回给上游:

# 拆分 libs/util 子树为临时分支，接下来推送
git subtree push --prefix=libs/util  main
}

““%E5%A4%A7””

“%EBF10B;"