Codex 负责写，Git 负责管
Codex 擅长「写代码」，但「版本管理」这件事，得你和 Git 一起把关。这一节讲 Codex 与 Git 命令怎么协同——让 Codex 的产出，稳稳地进入 Git 的可控流程。
file-lib 里，Codex 是「写代码的」，你是「管版本的」。每次 Codex 改完，你都要用 Git 命令审查它的产出再决定要不要提交。这一节我们用 git status / git diff 给 file-lib 的每次改动把一道「人审关卡」——先看再提交，让 Codex 的代码都过你的眼才进仓库。分工：Codex 写，Git 管
- Codex：改代码、写功能
- Git：记录改动、管理版本、控制合并
让 Codex 直接乱提交、乱合并？不行。你负责用 Git 把关它的产出。在 file-lib 里分工很清晰：
| 环节 | 谁来做 | 用什么 |
|---|---|---|
| 写功能代码 | Codex | 对话、编辑文件 |
| 看改了哪些文件 | 你（可让 Codex 辅助） | git status |
| 看具体改了什么 | 你 | git diff |
| 决定提交什么 | 你 | git add |
| 写提交信息 | Codex（你审） | git commit |
| 推远端、提 PR | 你 | git push |
一句话：Codex 出力，Git 把关，你做决定。
协同的关键操作
改之前：确认干净
让 Codex 干活前，先确认工作区干净：
git status # 看有没有未提交的改动
有未提交的，先处理，避免和 Codex 的改动混在一起。在 file-lib 里，如果上一个人（或上一个 Codex 会话）留了没提交的改动，你不清理就让新会话开工，两个会话的改动就会搅成一团，回滚都不知道是谁的。所以开工第一件事永远是 git status。
改之后：查看改动
Codex 改完，先审查改动再提交：
git status # 它改了哪些文件
git diff # 具体改了什么
先看 git diff，再决定要不要提交——这是人把关的第一步。对 file-lib 改完 lib/date.js 后，git diff 会告诉你它到底加了哪几行、有没有顺手动了不该动的 lib/string.js。看清楚了，提交才有底气。
让 Codex 帮你用 Git
Codex 也能帮你操作 Git（在你授权下）。比如：
帮我看看 git status，整理一下这次要提交的改动
或让它写提交信息：
帮我根据这次改动，按 Conventional Commits 写一条提交信息
Codex 辅助 Git 操作 + 人决定提交什么。对 file-lib，你可以让 Codex 干这种「整理活」：
我先不提交。帮我：
1. git status 看下工作区有哪些改动
2. 把改动按「本次 cli 功能相关 / 无关」分两组
3. 给相关的那组，按 Conventional Commits 拟一条提交信息
先别提交，等我确认。
Codex 帮你把改动理清、把信息拟好，但「提交不提交」始终握在你手里。
一个「协同」完整流程
1. git status（确认干净）
2. 让 Codex 干活
3. git status + git diff（人审查改动）
4. 认可 → 提交；不认可 → 让它改
5. git push → 提 PR
核心：Codex 的每一次改动，都过一遍 Git 的「审查关卡」。给 file-lib 跑一遍：
git status # 开工前确认干净
# 让 Codex 在 lib/date.js 加 leapYear 函数
git status # 看改了哪些文件
git diff lib/date.js # 看具体加了几行
# 认可 →
git add lib/date.js
git commit -m "feat(date): 新增 leapYear 闰年判断"
每一步 Codex 的改动都过了你的眼，才进了仓库。
关键原则
- 先看再提交：
git diff过了眼，才git add/commit - 别让 Codex 乱提交：提交什么、提交信息，人把关
- 改动可回退：提交后出问题，
git log能找到、能回滚
Git 是 Codex 改动的「安全网」——用好它，AI 再大胆也不怕。
git status 确认工作区干净；让 Codex 在 lib/date.js 加一个 leapYear 函数后，用 git status + git diff 审查它到底改了哪些文件、加了几行；认可后再 git add + git commit（提交信息用 Conventional Commits 格式）。②怎么判断做对了：改动只涉及 lib/date.js（没顺手动其他模块）、你亲自看过 git diff 才提交、提交后 git status 干净。③卡住了怎么办：如果 Codex 改完你不想提交的部分，用 git checkout -- <file> 撤销那个文件；如果提交信息没按规范，让 Codex 按 feat(scope): 描述 重拟。常见坑：git add . 把所有改动一把提交
和 Codex 协作时，很多人图省事用 git add . 把工作区所有改动一股脑提交。问题来了：Codex 可能这次会话改了三件事，其中一件是废的、一件是别人改的、只有一件是你要的。git add . 全给提交了，想拆开重来都难。
避坑办法：只提交「本次功能相关」的文件，逐个加，别用 .：
git add lib/date.js test/date.test.js # 只加相关的两个文件
git status # 提交前再核对一次
git commit -m "feat(date): 新增 leapYear"
提交前用 git status 再核对一遍「要提交的清单」，确认没有夹带。如果发现有不该提交的，git reset <file> 把它移出暂存区。宁可按文件逐个加，也不贪快用 git add .。 提交清单的干净，比提交速度重要得多。
小结
- 分工：Codex 写代码，Git 管版本，人把关
- 改前
git status，改后git diff审查 - 提交什么、提交信息，人决定，Codex 辅助
- 核心：Codex 每步改动都过 Git 审查关卡
下一节，讲冲突解决与变更管理。