git submodule status 是什么
查看每个子模块当前检出的提交与父仓库索引里记录的指针是否一致：输出行首的一个字符就是差异类型，后面依次是提交哈希、路径与描述。父仓库对子模块只记录提交指针而不是分支，所以「目录里的代码」与「父仓库记录的代码」随时可能不一致，status 就是检查这种偏差的第一入口，提交前自检与 CI 检出后核对都靠它。
基本信息
| 语法 | git submodule status [--cached] [--recursive] |
|---|---|
| 标记 | 空格=一致；-=未初始化；+=检出与记录不同；U=子模块内有合并冲突 |
| --cached | 只看父仓库索引里记录的指针，不读工作区状态 |
| 摘要 | git submodule summary 列出子模块内相对记录的提交变化 |
| 适用 | 任何含子模块的 Git 仓库；CI 检出目录同样适用 |
典型使用场景
- 提交父仓库前自检：确认所有子模块指针都停在预期提交，避免把本地实验状态提交进去。
- 构建疑似用了旧代码时定位：+ 说明目录里检出的提交与记录不同，先查这个再查构建脚本。
- CI 检出后核对：跑 status --recursive 确认所有层级子模块都按指针拉齐，再开始构建。
- 合并冲突后检查：U 表示子模块内部有冲突，需要进子模块目录解决后重新记录指针。
- 发布核对：对照发布 tag 逐一检查子模块指针与发布记录一致，防止漏更新。
常用示例
常用示例
git submodule status # 每个子模块一行：标记+提交+路径
git submodule status --cached # 只看父仓库索引里记录的指针
git submodule status --recursive # 连嵌套子模块一起查看
git submodule summary # 列出子模块内相对记录的提交变化
git submodule update --init --recursive # 按记录把工作区拉齐输出首字符读法
| 首字符 | 含义 | 处理办法 |
|---|---|---|
| 空格 | 检出提交与父仓库记录一致 | 无需操作 |
| - | 子模块尚未初始化，目录为空 | git submodule update --init 拉取 |
| + | 检出的提交与记录不同（本地改了或记录旧了） | 想清楚以哪边为准：update 或记录新指针 |
| U | 子模块内部存在合并冲突 | 进子模块目录解决冲突并提交 |
提交父仓库前用它做最后核对：出现 + 时先问自己「是本地改动了，还是父仓库记录旧了」，两个答案的处理方式正好相反；确认后要么提交新指针，要么 update 回记录版本。