先别急着从命令行对比，第一个要判断的是：这个子项目是跟着主项目一起发版，还是自己有独立节奏？如果子项目有独立发版节奏，且同时被多个父项目依赖，submodule 的固定提交哈希会更容易对齐版本；如果子项目几乎总是伴随主项目一起发布，subtree 会少一道初始化步骤，也避免子模块指向漂移导致构建不稳定。这个判断比单纯比较命令数量更接近实际痛点。
先用发布节奏做第一轮筛选
子项目有自己的发版节奏、被多个父项目依赖，或者主仓库的 CI/CD 不方便处理嵌套仓库的认证与权限时，submodule 能让每个子项目保持独立的权限边界和发布流程。如果子项目与主项目生命周期同进同退，几乎总是随主版本一起发布，subtree 能减少一次子模块初始化步骤，也避免子模块指向漂移导致的构建不稳定。这个判断直接决定后面所有命令和冲突处理方式。
核心区别：记录引用还是复制文件
先要把最根本的机制说清楚。
submodule将子项目作为独立仓库的一个引用记录在主仓库中，主仓库只保存子仓库的提交哈希；而subtree则是把子项目的文件直接复制进主仓库的目录树里，同时在主仓库中保留子仓库的历史。这个根本差异决定了后续所有行为：submodule在克隆主仓库后需要额外执行git submodule update --init --recursive才能拉取子项目内容，subtree则不需要任何额外命令，文件已经在工作区里。如果你希望团队成员克隆一次就能直接构建，subtree会更省事；如果子项目由多个团队分别维护且版本边界必须清晰，submodule的引用关系更自然。
这个差异还会影响你对“当前版本”的认知。submodule 的引用不会自动跟随子项目的最新提交，主仓库记录的永远是某个确定的哈希；subtree 则是把快照内容直接放进来。因此，查看线上问题对应的是哪一版子项目时，submodule 需要额外看一眼 `.gitmodules` 和当前 HEAD 的 gitlink，subtree 则可以直接在主仓库历史里找到当时的文件内容。两者没有谁更正确，只取决于你需要的可追溯粒度。
日常操作里的真正摩擦点
日常改代码时，submodule需要先进入子模块目录修改并提交，再回到主仓库更新引用哈希并提交，两个仓库各提交一次，很容易忘记第二次提交导致引用不更新；subtree则直接在主仓库中修改对应文件，提交时子项目的变更会与主仓库变更混合在一起。若要让subtree的改动回流到原始上游仓库，需要额外执行git subtree push --prefix=子目录 远程仓库 分支，若想从上游拉取更新则执行git subtree pull。这个额外命令的复杂度是subtree的主要摩擦点，而submodule在修改后回流时只需要在子模块仓库内正常push即可，流程更贴近多仓库协作习惯。
实际操作中，submodule 的两次提交可以通过 `git status` 看出征兆：在子模块目录里提交后，回到主仓库会看到该目录显示为 modified，这时需要再执行 `git add 子模块目录 && git commit`。如果忘记这一步，团队其他成员下次 `git submodule update` 时仍然拿到旧指针。subtree 这边则需要先确认 `--prefix` 目录是否稳定，频繁移动子目录位置后，`git subtree pull` 有可能会因为历史对不上而要求额外处理，这里要看你的 git 版本和仓库历史。
冲突和体积：藏得比较深的问题
多人同时修改同一个submodule时，子模块的指针冲突比普通文件冲突难解，因为需要先确认双方分别指向哪个子模块提交，再决定是否合并子模块自身的分支，操作步骤较多，新手容易把子模块弄脏；subtree则因为文件已经平铺进主仓库，冲突表现和普通文件冲突完全一样，解决方式直接，但代价是主仓库的pull或merge操作会包含子项目的大量文件差异，diff可读性差。若团队对git操作熟练度一般，subtree的学习成本更低；若团队已经习惯了多仓库并行开发，submodule反而更符合现有工作流。
处理 submodule 指针冲突时，建议先用 `git submodule status` 看双方各自指向哪个哈希，再去子模块仓库里对比分支，不要直接在父仓库里做 `git checkout` 覆盖。subtree 的冲突虽然好解决，但合并时主仓库的 diff 会把子项目的大量文件变更混在一起，代码评审阶段容易漏看真正有问题的改动。如果仓库体积敏感且子项目更新频繁，submodule 的主仓库历史更轻量；subtree 会把子项目历史带进主仓库对象库，长期使用后 `.git` 增长明显。
切换前建议先确认的检查点
先从 submodule 转 subtree，或从 subtree 转 submodule，都不是简单替换命令。submodule 转 subtree 时，原有的子模块引用会变成孤儿提交，需要先保留子模块的所有分支和 tag，再通过 `git subtree add` 把子仓库历史并入主仓库；反向切换时，要把子目录从主仓库历史中拆出，再在子模块仓库中建立等价历史，这个过程会重写主仓库的 commit hash，所有协作者都需要重新克隆而不是 pull。
切换前至少确认三件事，可以先跑这两条命令判断现状：
git submodule status
git log --grep='git-subtree-dir' --oneline- 如果第一条输出子模块路径和哈希，说明当前仓库在用 submodule；如果第二条能查到带 git-subtree-dir 的提交，说明已经有过 subtree 操作。两条都没有，说明子项目可能只是普通目录，还没纳入任何管理。
- 主项目是否有依赖旧引用的脚本或 CI 步骤：例如读取 `.gitmodules`、按子项目哈希拉制品，切换后这些判断都会失效。
- 子项目文件是否完整保留：先在临时分支上演练一遍，逐项对比子项目目录的文件内容，确认没有丢失，再对团队公布迁移指令。
最后回到选择题本身：submodule 和 subtree 的取舍并不是看哪个“更先进”，而是看你的发布模型、团队协作习惯和仓库体积容忍度。建议先把当前仓库的使用方式、子项目的发版节奏、CI 是否方便处理嵌套仓库这三件事列出来，再决定要不要动手改。