git submodule update 默认只检出父仓库锁定的提交，不自动拉取远程更新；需先 git fetch 再用 --remote 参数同步最新默认分支。
git submodule update 为什么没拉到最新提交
因为 git submodule update 默认只检出子模块当前记录的提交（即父仓库 commit 中锁定的 SHA），不会自动 fetch 远程更新。它不是“拉新代码”，而是“还原已知状态”。
常见错误现象：git submodule update 执行后子模块目录内容没变，git log 看不到上游新提交。
- 想同步远程最新，得先让子模块知道远程有啥新东西：进每个子模块目录运行
git fetch，或在根目录用git submodule foreach git fetch - 再用
git submodule update --remote（不是--rebase或--merge）——它会自动 fetch + checkout 远程origin/HEAD指向的提交 -
--remote默认跟踪的是子模块 .gitmodules 里配置的branch字段；如果没配，就用远程默认分支（通常是main或master）
如何让所有子模块统一更新到各自远程的最新 default 分支
这是最常用、也最安全的批量同步方式，适合日常开发中保持子模块跟上游主线一致。
使用场景：CI 构建前拉最新依赖、本地开发需要尝鲜 upstream 修复、团队约定子模块只用默认分支。
- 执行
git submodule update --remote --recursive——--recursive是必须的，否则嵌套子模块不动 - 如果子模块的 .gitmodules 中没写
branch = xxx，它会按远程仓库的 HEAD 来决定拉哪个分支，但这个行为不可靠（比如 GitHub 可能改了 default branch，本地却没感知） - 建议提前检查并显式配置：修改 .gitmodules，给每个子模块加上
branch = main（或对应分支名），再git add .gitmodules && git commit - 注意：这会改变父仓库的工作区状态，更新后记得
git add子模块目录并提交，否则别人拉不到你的新指针
git submodule foreach 脚本里怎么判断是否真的更新了
批量操作时，光看命令没报错不等于代码变了。有些子模块远程压根没新提交，git pull 后 HEAD 不动，但父仓库仍可能误记为“已更新”。
性能影响：遍历每个子模块执行 git rev-parse HEAD 对比前后值，开销很小；但若用 git status 或 diff，则慢得多。
- 推荐做法：在
foreach中用git merge-base --is-ancestor判断当前 HEAD 是否已包含远程最新提交 - 简短示例：
git submodule foreach 'git fetch && git merge-base --is-ancestor origin/HEAD HEAD || echo "→ $sm_path needs update"' - 别用
git pull代替fetch + reset --hard：pull 可能触发合并，产生意外 commit；而 submodule 应该是可重现的只读引用 - Windows 下
foreach的 shell 语法容易崩，建议用 Git Bash 或 WSL，避免 cmd/PowerShell 直接跑复杂逻辑
更新后发现编译失败，问题大概率不在子模块本身
子模块代码确实更新了，但项目构建失败，往往是因为接口变动、ABI 不兼容，或父仓库没适配新版本的调用方式。
容易被忽略的地方：子模块更新只是“换了个 commit”，不等于“能直接用”。尤其 C/C++ 项目，头文件变更、符号删除、CMakeLists 改动都会导致构建中断。
- 先确认子模块是否真被推进了：
git diff HEAD@{1} --submodule（显示 submodule commit 差异） - 检查子模块的 CHANGELOG 或 release tag，看是否有 breaking change 提示
- 如果子模块用了
git subtree混合管理（少见但存在），submodule update完全无效，得另查历史 - CI 环境里务必加
git submodule sync—— 它会重置子模块的 remote URL，防止因 fork 或镜像源不同导致 fetch 失败
