Git 提交前检查

Git 提交前检查

这一篇讲提交前最后一道关。

前面你已经让 Codex 完成了修改和任务验收，但这还不等于可以提交。提交前还要确认：

改了哪些文件
这些文件是否都和任务有关
有没有把密钥、截图、临时文件、构建产物带进去
检查结果是否可信
提交说明该怎么写
如果提交后出问题，能不能回滚

前置教程：让 Codex 完成任务验收
如果你还不知道如何让 Codex 汇报验收结果，先完成前置教程，再回到本篇。

依据来源：OpenAI Codex 官方手册中关于 Git diff、任务总结、验证、审批和安全边界的说明。

本篇目标

跟着本篇做完后，你应该能做到：

1. 让 Codex 在提交前检查 Git 状态。
2. 让 Codex 汇总本次 diff。
3. 判断是否有无关文件。
4. 判断是否包含敏感信息。
5. 判断验收是否足够。
6. 让 Codex 生成提交说明。
7. 决定是否可以提交。

本篇不做什么

本篇不直接教你手动提交。

原因是：用户在不同项目里可能用 CLI、IDE、Git 图形工具或远程仓库流程。本站先教你怎么判断“能不能提交”，后续再单独写提交操作。

本篇也不让 Codex 自动提交。新手阶段，提交动作应该由用户最终确认。

第 1 步：让 Codex 做提交前总检查

在 Codex 里复制这段：

请做一次提交前检查。

要求：
1. 只检查，不要修改文件。
2. 不要提交 Git。
3. 请检查当前 Git 状态。
4. 请总结本次 diff。
5. 请判断是否存在无关文件变化。
6. 请判断是否可能包含密钥、账号、token、截图隐私或临时文件。
7. 请结合前面的任务目标，判断是否可以进入提交。

请按下面格式输出：

## Git 状态
- 当前分支：
- 变化文件列表：

## Diff 摘要
- 每个文件改了什么：
- 是否符合任务目标：

## 风险检查
- 是否有无关文件：
- 是否有敏感信息：
- 是否有构建产物或临时文件：
- 是否有大范围格式化：

## 验收回顾
- 已经做过哪些检查：
- 哪些检查通过：
- 哪些检查失败：
- 哪些检查没有做，原因是什么：

## 提交建议
- 是否建议提交：
- 如果建议提交，提交说明建议写什么：
- 如果不建议提交，下一步应该做什么：

第 2 步：看变化文件列表

你先看变化文件是不是都认识。

理想情况：

modified: src/App.vue

或者：

modified: README.md

需要警惕的文件：

• .env
• .env.local
• config.toml
• auth.json
• node_modules
• dist
• .astro
• 截图原图
• 包含 Key 的 Markdown
• 你没让 Codex 改的业务文件

如果出现不认识的文件，先问：

变化文件里有我不认识的文件。请逐个解释这些文件为什么变化，以及是否和本次任务直接相关。不要修改文件。

第 3 步：检查敏感信息

提交前一定要让 Codex 检查敏感信息。

复制这段：

请专门检查本次 diff 是否可能包含敏感信息。

重点检查：
1. API Key。
2. token。
3. Cookie。
4. 账号、邮箱、手机号。
5. 内网地址。
6. 数据库连接串。
7. 截图里的隐私信息。
8. 本地绝对路径中是否暴露不该公开的信息。

要求：
- 只检查，不要修改文件。
- 如果发现风险，请列出文件和原因。
- 不要把疑似密钥完整打印出来。

如果 Codex 发现疑似密钥，不要让它在回答里完整展示密钥。让它只说文件路径和风险类型。

第 4 步：检查是否有无关修改

有时候 Codex 会顺手格式化、顺手修旧问题、顺手调整其他文件。

提交前要问：

请判断本次 diff 中是否存在无关修改。

判断标准：
1. 是否和本次任务目标直接相关。
2. 是否为了通过本次验收必须修改。
3. 是否只是顺手优化。
4. 是否属于历史问题。

请把修改分成三类：
- 必须保留。
- 可以保留但建议单独提交。
- 建议撤回。

只分析，不要修改文件。

这一步能避免一个提交里混进太多东西。

第 5 步：确认验收结果够不够

提交前不要只看“已完成”。

复制这段：

请判断本次任务的验收是否足够进入提交。

请回答：
1. 任务目标是否完成。
2. 是否运行了最小必要检查。
3. 检查结果是什么。
4. 如果没有运行检查，跳过是否合理。
5. 是否还需要人工打开页面或手动确认。
6. 是否存在已知失败项。

最后请给出结论：
- 可以提交。
- 暂不提交，需补检查。
- 暂不提交，需继续修复。

如果 Codex 说“可以提交”，它必须说明依据。

第 6 步：让 Codex 生成提交说明

如果前面都通过，再让 Codex 生成提交说明。

复制这段：

请根据本次 diff 生成 3 个提交说明候选。

要求：
1. 使用简短中文。
2. 不夸大范围。
3. 不写没有做过的事。
4. 如果是文档修改，以 docs 开头。
5. 如果是功能修改，以 feat 开头。
6. 如果是修复，以 fix 开头。
7. 如果只是样式，以 style 开头。

请同时说明你推荐哪一个，以及原因。

示例：

docs: 补充 Codex 任务验收教程

或者：

feat: 调整首页标题文案

第 7 步：最后确认一遍

提交前最后问一次：

请做最后提交前确认。

请只回答：
1. 当前是否还有未解释的文件变化。
2. 是否发现敏感信息。
3. 是否存在建议撤回的文件。
4. 是否可以提交。

不要修改文件，不要提交。

如果 Codex 说还有未解释变化，不要提交。

如果 Codex 说发现敏感信息，不要提交。

如果 Codex 说建议撤回某些文件，先处理。

常见问题

情况 1：Codex 建议提交，但你不放心

继续问：

请站在代码审查者角度，重新检查本次 diff 可能被 reviewer 挑出的 5 个问题。只分析，不要修改。

情况 2：Codex 发现无关文件

继续问：

请说明这些无关文件是否可以单独撤回。先给方案，不要直接执行。

情况 3：Codex 发现敏感信息

先不要提交。

继续问：

请告诉我疑似敏感信息所在文件和风险类型，不要完整打印敏感内容。请给出移除方案，先不要修改。

情况 4：检查没跑，但 Codex 说可以提交

继续问：

你没有运行最小必要检查，却判断可以提交。请说明依据。如果依据不足，请补充最小必要检查。

验收结果

做到这里，如果满足下面 7 条，就说明本篇完成：

1. Codex 已列出变化文件。
2. Codex 已解释 diff。
3. Codex 已检查无关文件。
4. Codex 已检查敏感信息。
5. Codex 已回顾验收结果。
6. Codex 已给出是否建议提交。
7. Codex 已生成不夸大的提交说明。

本篇你真正学会了什么

你学会的是：

提交不是保存结果，而是把一组经过解释和验收的变化放进历史。

让 Codex 写代码只是第一步。让它帮你在提交前解释清楚“改了什么、为什么能交付、有没有风险”，才是专业 vibe coding 的关键。

下一篇学什么

下一篇看：怎样写一个合格的 Codex 任务。

那一篇会把前面几篇里反复出现的提示词结构抽象成一套通用写法。