Codex 改了子模块，主仓库为什么只显示一行变化

Codex 改了子模块后，主仓库常只显示目录的一行变化。验收时必须同时核对子模块内容提交与主仓引用：前者回答代码是什么，后者回答项目将使用哪个版本。本文交付一个双仓发布核对表，重点验证别人能否拿到相同内容。

把两层状态放在同一张表

假设主仓包含 vendor/rules 子模块，任务是修正其中的合成校验规则。先分别记录提交号与未提交状态，不能只截主仓状态图。

git status --short
git submodule status -- vendor/rules
git diff --submodule=log -- vendor/rules
git -C vendor/rules rev-parse HEAD
git -C vendor/rules status --short
git -C vendor/rules diff

目录名只是演示，需替换成项目实际子模块。不要凭 .git 是文件就下结论，关联工作树也可能使用这种形式；结合 .gitmodules 与子模块命令确认身份。

核对项	修改前	修改后	交付证据
子模块内容提交	C0	C1	C1 的具体文件差异
子模块工作区	干净或已知变化	无遗漏任务文件	子仓状态清单
主仓记录引用	C0	C1	主仓暂存差异
远端可取性	C0 可取	C1 待验证	新检出获取记录
主仓集成检查	基线结果	新结果	命令和退出码

提交号用 C0、C1 表示合成示例，正式记录需填完整真实值。子仓还有未提交内容时，主仓引用无法表达那些字节；本机集成测试可能依赖它们而侥幸通过。

两种容易被误认为完成的状态

第一种，子模块文件改了但没有形成内容提交，主仓显示“脏”，却没有新的可重现引用。第二种，子模块形成本地提交且主仓也引用它，但该提交只存在本机。两者在当前电脑都可能运行，新的检出却无法取得同样状态。

因此，验收不只看 git diff 从一行变成另一行。先确认子仓具体差异符合任务、测试通过、提交归属正确，再确认指定远端能提供该提交。涉及推送时遵守项目授权和分支规则；这里的核对表不是要求向任何未知远端发布代码。

在另一目录模拟接手者

用项目认可的方式取得主仓目标提交并初始化子模块，记录实际拉到的子仓提交是否等于 C1。随后在不带本机未提交文件的情况下运行必要检查。若只能在当前目录测试，应如实写“尚未完成干净检出验证”，不能用当前 HEAD 一致替代远端可取性。

子模块本身如果依赖 LFS、生成物或私有包，还要逐项验证这些前提。主仓引用正确只能保证指向正确的子仓提交，不会自动保证额外资产存在。必要的合成输入应纳入其所属仓库或附件清单。

交给工具的任务说明

可以写：“只改 vendor/rules 的指定规则；先报告父子仓当前提交与已有变化；完成后提供子仓差异、目标提交、主仓引用及干净检出结果。”如果子仓处于游离 HEAD，先保存现场并决定合适的分支承载方式，不要自动切默认分支把已有任务甩开。

常见问题

主仓只有一行变化是否没改代码？ 不能这样判断，具体内容在子仓提交里。

子仓测试通过是否代表主仓通过？ 不代表，调用接口或引用版本仍可能不同，应补集成检查。

可以把子模块文件直接复制进主仓吗？ 那会改变版本管理方式，属于另一个任务，不能作为当前验收的捷径。

继续处理相关问题

相关入口：Codex 会话管理。

官方依据与核对日期

核对日：2026-10-23。Git submodule：主仓记录子模块提交，子仓工作区与引用需要分别核对；Git diff 子模块比较：submodule 格式可显示引用对应的提交变化。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。