Appearance
Codex Git 工作流：分支、Diff、测试与提交怎么配合
Codex 生成代码的速度很快，但团队真正关心的是改动是否可追踪、可验证、可回滚。把 Codex 放进清晰的 Git 工作流，可以把“看起来能用”的结果变成可审查的提交。
开始前确认工作区
进入项目根目录，先查看分支和未提交修改：
bash
git status --short --branch
git branch --show-current如果工作区已经有未提交的用户修改，先告诉 Codex 哪些内容必须保留。不要让它为了完成新任务自动重写未知改动。
一个任务对应一个小分支
为可回滚的任务创建独立分支：
bash
git switch -c fix/auth-timeout分支名称写清目标，不要把多个无关需求混在一起。任务开始时让 Codex先阅读 AGENTS.md，并说明允许修改的目录、不能改的生成文件和验证命令。
先计划，再编辑
推荐提示词：
text
请先阅读当前 diff 和相关测试，只输出实现计划，不修改文件。
目标：修复登录请求超时后没有释放 loading 状态。
范围：src/auth、tests/auth。
完成标准：新增回归测试，运行受影响测试和构建。计划确认后再让 Codex实现。若任务扩大到其他模块，先更新范围和验证标准。
用 Diff 做第一次审查
bash
git diff --stat
git diff --check
git diff重点检查：是否改了范围外文件、是否混入格式化噪声、错误路径是否有测试、日志是否泄露敏感数据、配置是否带入密钥。git diff --check 能发现空白错误，但不能代替代码审查。
测试和提交边界
先运行最接近修改的测试，再运行类型检查和构建。让 Codex明确汇报每条命令的结果；失败时区分已有失败和本次改动造成的失败。
确认通过后再提交：
bash
git add src/auth tests/auth
git commit -m "fix: handle auth request timeout"只暂存任务相关文件。不要用 git add . 把本地密钥、构建产物或其他任务的修改一起提交。
Pull Request 前的 Codex 审查
把最终 diff 交给 Codex做一次只读审查：
请审查当前分支相对主分支的 diff。按严重程度报告行为回归、边界条件、错误处理、安全风险和测试缺口。只报告有代码证据的问题，并给出文件和行号，不要修改文件。
审查结果仍需人工确认。可复用的审查流程见 用 Codex 做代码审查。
什么时候不要让 Codex自动提交
涉及生产配置、数据库迁移、权限策略、依赖升级或删除数据时，保留人工确认。Codex可以准备 diff 和迁移说明，但提交、合并和发布应由负责人检查影响范围。
FAQ
Codex 会自动创建 Git 提交吗？
取决于你的指令和当前工作流。默认应把提交作为明确步骤，先检查 diff、测试和暂存范围。
可以让 Codex 直接修改主分支吗？
小型个人项目可以，但团队仓库更适合使用独立分支和 Pull Request，以便审查和回滚。
为什么测试通过还要看 Diff？
测试只覆盖已有场景，不能发现无关文件被修改、密钥进入仓库或配置被意外改变。Diff 是最直接的范围检查。