Codex GitHub 提交错误：工作流常见错误和修复顺序

Codex 能快速改文件，但 GitHub 提交流程需要慢一点。新手常见错误是：工作区没看就提交、直接推主分支、PR 描述只有一句话、CI 没过也交付，甚至把临时文件或敏感配置带进仓库。

这篇是草稿，只做复盘参考，不替代具体项目人工审核。还没有固定流程的，先看 GitHub 提交流程主文 和 提交检查清单。

适合谁

适合已经用 Codex 改过代码、但还不稳定掌握 GitHub 提交流程的新手。尤其是每次提交前都要想半天：哪些文件该 add，哪些命令该跑，PR 该写什么。

也适合复盘客户项目的人。提交记录、PR 描述和 CI 结果都是你的交付证据，不只是开发者内部流程。

不适合谁

不适合没有客户授权、却访问私有仓库或高权限配置的人。也不适合涉及生产部署、账号权限、支付配置、真实数据和安全漏洞但没有人工复核的任务。

如果你连 diff 都说不清，就不要急着提交。先回到本地记录，把改动解释清楚。

风险提醒

GitHub 的错误通常会留下历史。敏感内容一旦提交，删除文件不一定能解决；主分支一旦触发部署，错误可能直接影响线上。遇到不确定，先暂停。

错误一：没看工作区

git status 为空和不为空，是两种完全不同的开工状态。新手如果不看工作区，可能把客户已有改动、自动生成文件或旧任务残留一起提交。

修复方式：每次开始和提交前都运行 git status。对不认识的文件，先查来源，不要直接 git add .。

错误二：直接推主分支

直接推主分支可能触发部署，也会减少代码审查机会。客户小项目不一定有严格分支规则，但这不代表你应该省略安全缓冲。

修复方式：为任务创建分支，提交到分支，再通过 PR 或交付补丁说明范围。如果客户明确要求直接提交，也要先确认影响和回滚方式。

错误三：PR 描述空泛

只写“fixed bug”或“updated files”，客户不知道你做了什么、怎么验证、哪些没覆盖。后续出问题时，你也缺少交付证据。

修复方式：PR 描述至少包含目标、修改范围、验证命令、验证结果、未覆盖范围、客户待确认事项。

错误四：没跑检查

Codex 改出来的代码可能能看，但不一定能构建、能测试、能通过 lint。没有检查就提交，会把验证责任推给客户。

修复方式：优先跑项目已有命令。没有命令时，也要做最小人工检查，例如打开页面、复现问题、检查截图或阅读生成内容。

错误五：提交敏感文件

.env、token、私钥、日志、截图、导出数据、构建产物都可能被误提交。尤其是新手喜欢用 git add .，风险更高。

修复方式：提交前搜索敏感关键词，检查新增文件列表。发现真实密钥已进入提交时，先通知客户轮换或撤销凭证，再按项目流程清理。

具体步骤：发现提交错了怎么补救

1. 暂停继续推送、合并或部署。
2. 查看 git status、git log -1 和最近 diff。
3. 判断错误是否已经推到远端。
4. 区分无关改动、敏感内容、未验证代码和错误提交信息。
5. 对敏感内容，先记录范围并通知客户确认轮换。
6. 对无关改动，拆出或恢复，重新提交最小范围。
7. 对未验证代码，补跑检查并更新 PR 描述。
8. 对需要授权、合并、部署的动作，列为客户待确认。

复盘模板

错误类型：
发生位置：
是否推送远端：
影响范围：
已处理：
客户待确认：
下次新增检查项：

补救后怎么验收

补救完成后，不要只看当前分支干净。你还要确认目标任务仍然完成、无关改动已经移除、敏感内容没有残留、检查命令已经重新跑过、PR 描述已经更新。如果之前错误已经推到远端，还要说明远端影响范围。

对于客户项目，补救记录要写给人看，而不是只留在本地命令历史里。客户不需要知道每个细节，但需要知道问题是什么、你做了什么、还有什么需要他确认。

CTA：下一步

如果你想避免重复踩坑，把 GitHub 提交检查清单 放进每次项目记录。需要写客户交付说明，可以用 Proposal 生成器 起草，再人工补验证和未覆盖范围。

免责声明

本文只用于 AI 工具实践流程学习和草稿复核，不构成法律意见、安全审计、职业建议或具体项目交付承诺。真实项目应以客户授权、平台规则、仓库规则和人工复核为准；需要登录、授权、合并、部署或高权限操作的事项，应先记录并由客户确认。