Codex 怎么配合 Git 使用？修改前、修改后、回滚前分别该做什么

用 Codex 改代码时，我最强烈的建议是：一定要配合 Git 使用。

Codex 很适合帮我们读代码、改代码、排查 bug、补文档、做 review。但只要它开始修改文件，问题就来了：你要知道它改了什么、哪些改动可以留下、哪些改动应该撤掉、出了问题能不能回到修改前。

这时候 Git 就很重要。

OpenAI 官方文档里也建议，在让 Codex 开始任务前后创建 Git checkpoint，方便后续回退；Codex 的 code review 功能也依赖 Git 仓库里的 diff 来检查改动。简单说，Git 是你和 Codex 协作时的“安全绳”。

这篇文章就按实际使用流程讲清楚：

修改前应该做什么
  -> Codex 修改过程中怎么看 diff
  -> 修改后怎么检查和提交
  -> 回滚前应该怎么判断

一、为什么 Codex 一定要配合 Git

如果你只是让 Codex 解释代码，不一定需要 Git。

但只要你让它做这些事，就建议先准备好 Git：

• 修改业务代码
• 重构模块
• 新增文件
• 删除无用逻辑
• 调整依赖和配置
• 批量改文档
• 修复 bug

原因很简单：Codex 可以帮你做事，但你仍然需要判断它做得对不对。
Git 能让你看到完整改动，也能让你在不满意时撤回。

我自己的习惯是：

没有 Git，不让 Codex 大改。
工作区不干净，不让 Codex 直接动手。
任务太大，不让 Codex 一次做完。

二、修改前：先确认工作区是否干净

第一步永远是看状态。

git status

如果输出里有 modified、deleted、untracked，就说明当前工作区已经有改动。

这时候先别急着让 Codex 修改。你要先判断这些改动是谁做的：

• 是你刚才手动改的
• 是上一轮 Codex 改的
• 是编辑器自动格式化的
• 是临时文件或构建产物

如果你在一个已经很乱的工作区里继续让 Codex 改，后面很容易分不清“哪些是它改的，哪些是原本就有的”。

三、修改前：最好新建一个分支

如果任务稍微复杂一点，建议单独开分支。

git switch -c codex/fix-login-error

分支名可以按任务来起：

codex/fix-login-error
codex/add-readme
codex/refactor-auth
codex/update-api-client

这样做的好处是：

• 当前任务有独立边界
• 不会直接污染主分支
• 后续可以单独提交、单独回滚
• 如果改坏了，直接丢弃这个分支也更轻松

如果你不想建分支，至少也要保证当前分支已经有一个干净的提交点。

四、修改前：把已有改动先处理掉

如果 git status 显示有未提交改动，通常有三种处理方式。

方式一：先提交

如果这些改动已经完成，可以先提交：

git add .
git commit -m "保存当前工作进度"

然后再让 Codex 开始新任务。

方式二：先 stash

如果这些改动还没完成，但又想临时放起来，可以用：

git stash push -m "临时保存修改"

后面需要恢复时再看：

git stash list
git stash show -p stash@{0}
git stash apply stash@{0}

Git 官方文档里对 stash 的描述很直接：它适合临时保存当前工作目录和暂存区状态，然后让工作区回到干净状态。

方式三：先开新 worktree

如果你手头的改动不能动，但又想让 Codex 做另一个任务，可以考虑单独开一个 worktree。

这个方式更适合熟悉 Git 的用户。它的好处是：你可以给 Codex 一个干净目录，让它只在那个目录里做当前任务。

五、给 Codex 的第一个提示词：先看状态，不要动手

在真正修改前，可以先这样问：

请先检查当前项目的 Git 状态，不要修改任何文件。
告诉我：
1. 当前分支是什么
2. 是否有未提交改动
3. 是否有未跟踪文件
4. 是否适合开始新的修改任务

这个提示词很实用。
它能让 Codex 先帮你看一眼当前现场。

如果状态不干净，你可以继续让它解释：

请根据当前 Git 状态，帮我判断哪些文件可能是本次任务无关改动。
不要修改文件，只做分析。

六、修改中：让 Codex 小步提交思路，而不是一次改到底

不要一上来就说：

帮我重构整个登录模块。

更稳的方式是拆成三步。

第一步，定位：

请先定位登录模块相关文件，不要修改代码。
列出相关组件、接口调用、状态管理和错误处理位置。

第二步，方案：

请给出最小修改方案。
要求说明准备修改哪些文件、每个文件改什么、可能有什么风险。
暂时不要动手。

第三步，执行：

可以按方案修改。
只修改刚才列出的文件。
不要做无关优化。
修改后告诉我实际改了哪些文件。

这样 Git diff 会更清楚，后续 review 和回滚也更容易。

七、修改中：随时看 diff

Codex 改完一轮后，不要急着继续给新任务。
先看 diff。

看所有改动概览：

git diff --stat

看具体未暂存改动：

git diff

看已经暂存的改动：

git diff --staged

Git 官方文档里说明，git diff 可以查看工作区相对于暂存区的变化，git diff --staged 则用于查看已经暂存、准备提交的变化。

如果你只想看某个文件：

git diff -- src/pages/Login.tsx

这个习惯非常重要。
Codex 说它只改了 A 文件，但你最好自己用 Git 再确认一次。

八、修改后：让 Codex 写变更摘要

修改完成后，可以让 Codex 做一次总结：

请总结本轮修改：
1. 修改了哪些文件
2. 每个文件改了什么
3. 为什么这样改
4. 是否存在风险点
5. 如何手动验证

然后你再对照：

git diff --stat
git diff

如果 Codex 的总结和 Git diff 对不上，就要提高警惕。

九、修改后：先 review，再提交

如果你用的是支持 /review 的 Codex 环境，可以让它 review 当前改动。

/review

也可以手动写：

请 review 当前未提交改动。
重点检查：
1. 是否有回归风险
2. 是否有边界情况遗漏
3. 是否有无关修改
4. 是否有潜在安全问题
5. 是否需要补测试

OpenAI 官方文档说明，Codex 可以 review uncommitted changes、commit 或 base branch，并且 review 过程不会修改工作区。这个特性很适合提交前检查。

十、修改后：分批暂存，不要无脑 add .

如果改动很小，git add . 问题不大。

但如果 Codex 改了多个文件，建议分批暂存：

git add src/pages/Login.tsx
git add src/utils/auth.ts

如果你想更精细一点，可以用：

git add -p

这样可以按 hunk 选择要提交的内容。

为什么不建议长期无脑 git add .？

因为它可能把这些东西也加进去：

• 临时文件
• 日志文件
• 本地配置
• 调试代码
• Codex 顺手生成但你不需要的文件

提交前再看一次：

git diff --staged

确认没问题后提交：

git commit -m "fix: improve login error message"

十一、回滚前：先判断你要撤的是哪一种改动

回滚不是一个命令解决所有问题。
你先要判断自己要撤掉的是什么。

场景	建议操作
某个文件的未暂存修改不想要了	git restore <file>
某个文件已经暂存，但想取消暂存	git restore --staged <file>
想撤掉某个新文件	先确认文件内容，再手动删除
想撤掉本次 Codex 全部未提交修改	先看 git diff，再逐个 restore
已经提交了，但还没推送	视情况新建修正提交，或用 reset
已经推送了	更建议用 git revert 生成反向提交

我不建议新手一上来就复制危险命令。
尤其是 git reset --hard 和 git clean，它们会丢弃大量本地内容，除非你非常确定，否则不要随手用。

十二、回滚前：让 Codex 先解释，不要让它直接删

如果你不确定该怎么撤，可以先这样问 Codex：

请根据当前 Git diff，判断如果我要撤回本次修改，应该撤哪些文件。
不要执行任何回滚命令，只给我建议。

再让它具体一点：

请把当前修改分成三类：
1. 建议保留
2. 可以撤回
3. 需要我人工确认
不要修改文件。

这一步能避免你一冲动把有用改动也删掉。

十三、一个安全的回滚流程

如果你想撤掉 Codex 的某次修改，可以按这个顺序来：

1. git status
2. git diff --stat
3. git diff
4. 让 Codex 解释哪些改动属于本次任务
5. 只 restore 明确不要的文件
6. 再次 git diff 确认结果

对应命令大概是：

git status
git diff --stat
git diff
git restore src/pages/Login.tsx
git diff --stat

重点是：先看，再撤。

不要在没看 diff 的情况下直接清空所有修改。

十四、一个完整示例：让 Codex 修登录报错

假设你要让 Codex 修登录失败提示。

第一步：准备 Git 环境

git status
git switch -c codex/fix-login-message

第二步：让 Codex 先定位

请先定位登录失败提示相关代码，不要修改任何文件。
告诉我相关页面、接口调用和错误处理分别在哪里。

第三步：让 Codex 给方案

请给出最小修改方案。
目标：登录失败时展示更明确的错误提示。
要求：不改变登录接口，不影响注册页面。
暂时不要修改代码。

第四步：允许修改

可以按方案修改。
只修改登录页面和错误提示相关文件。
不要做无关重构。

第五步：检查 diff

git diff --stat
git diff

第六步：让 Codex review

请 review 当前修改。
重点检查是否影响正常登录、注册跳转、表单校验和错误提示展示。

第七步：提交

git add src/pages/Login.tsx
git commit -m "fix: improve login error message"

这样一套下来，你会非常清楚：

• 任务从哪里开始
• Codex 改了什么
• 改动有没有越界
• 如果出问题怎么回退

十五、适合收藏的提示词模板

修改前

请先检查当前 Git 状态，不要修改任何文件。
告诉我当前分支、未提交改动、未跟踪文件，以及是否适合开始新任务。

修改中

请只完成当前任务，不要做无关优化。
如果发现需要修改额外文件，请先说明原因，等我确认。

修改后

请总结本轮修改：
1. 改了哪些文件
2. 每个文件改了什么
3. 有哪些风险
4. 如何验证

回滚前

请根据当前 Git diff，判断哪些改动应该保留，哪些可以撤回，哪些需要人工确认。
不要执行任何回滚命令。

十六、总结

Codex 和 Git 搭配起来，真正的价值不是“让 AI 随便改代码”，而是让整个过程可控：

修改前有 checkpoint
修改中能看 diff
修改后能 review
不满意能回滚
最终能提交成清晰 commit

我现在用 Codex 的基本原则是：

1. 先看 git status
2. 复杂任务先开分支
3. Codex 先分析，再修改
4. 改完先看 diff
5. 提交前让它 review
6. 回滚前先让它解释改动

这样用起来会稳很多，也更像一个正常的开发协作流程。

P.S. 我自己的AI中转站正在招募试用用户，感兴趣可以随时评论区私信交流

参考资料

• Codex CLI: https://learn.chatgpt.com/docs/codex/cli
• Codex Code Review: https://learn.chatgpt.com/docs/code-review
• Codex Best Practices: https://learn.chatgpt.com/guides/best-practices
• Git Cheat Sheet: https://git-scm.com/cheat-sheet
• Git diff documentation: https://git-scm.com/docs/git-diff
• Git stash documentation: https://git-scm.com/docs/git-stash