让 Codex 干活，但要「隔离」在分支里
Codex 能高效写代码，但它也可能搞乱。安全接进 Git 工作流的第一步：让它在独立分支里干活，改完提 PR，人审完再合并。这样它再大胆，也不污染主干。
这一节讲「分支 + 提交 + PR」的协作方式。
file-lib 是一个多人协作的项目：你、同事、还有 Codex。为了让 Codex 的每一次改动都「有轨可循」，我们从现在起把 file-lib 的每项功能都放到独立分支里做。今天这一节，我们用分支 + PR 给 file-lib 上一个「cli 命令」功能，让 Codex 在 feature/cli 分支里干活，走完整的提交、PR、合并流程。为什么要用分支隔离
如果 Codex 直接在主分支改，问题很严重：
- 改到一半的半成品污染主干
- 它乱改的代码所有人都看得到
- 出问题难回滚
分支隔离：Codex 在独立分支干活，主干保持稳定，出问题只影响分支。
main（主干，受保护）
└─ feature/login ← Codex 在这里干活
→ 提交 → 提 PR → 评审 → 合并回 main
对 file-lib 来说，主干 main 永远是可发布、可用的稳定版本，Codex 的所有「新点子」都在 feature/* 分支上先试。试成了合并，试砸了删掉分支，主干毫发无损。
一套「分支协作」流程
1. 从主干新建分支：git checkout -b feature/login
2. 在分支里让 Codex 干活
3. 它改完，git 提交
4. 推到远端，提 PR
5. 评审通过 → 合并回主干
6. 删除已合并的分支
每一步都让「Codex 的改动」处于可控轨道。给 file-lib 的 feature/cli 完整走一遍：
git checkout -b feature/cli # 1. 新建分支
# 2. 让 Codex 在分支里实现 cli 命令
git add . && git commit -m "feat(cli): 新增命令行入口" # 3. 提交
git push -u origin feature/cli # 4. 推远端，提 PR
# 5. 评审通过 → 合并
git checkout main && git branch -d feature/cli # 6. 合并后删分支
六步走完，Codex 的「cli 功能」从想法到上线，全程在分支轨道上，每一步都有记录。
提交信息：让改动可追溯
提交信息写清楚，别人（和未来的你）才知道这次改了什么。可以用规范格式：
feat(auth): 增加登录接口
- 新增 POST /api/login
- 增加邮箱格式校验
- 补充 3 个测试用例
让 Codex 遵循团队提交规范（下一节细讲）。对 file-lib 的 cli 改动，规范的提交信息长这样：
git commit -m "feat(cli): 新增命令行入口
- 新增 bin/cli.js，支持 --dir 指定目标目录
- 在 package.json 注册 bin 字段
- 为 cli 补充 2 个冒烟测试"
多行提交信息里，标题一行点明「改了什么功能」，正文列出要点，未来的你翻 git log 一眼就能看懂这次提交干了啥。
PR 的作用
PR（Pull Request）是把改动「摆到台面上」给团队看的地方：
- 展示改了什么、为什么改
- 别人能审、能评论
- 合并有记录，可回溯
PR 不是流程负担，是「让 AI 改动可审查」的关键一步。 对 file-lib 来说，每次 PR 你可以在描述里写清三件事：
## 做了什么
为 file-lib 新增 cli 命令，支持 --dir 指定目录
## 改动范围
- bin/cli.js（新增）
- package.json（bin 字段 +1 行）
- test/cli.test.js（新增）
## 请重点审
- cli 解析参数有没有边界问题
- 会不会破坏已有模块的导出
写清「做了什么、改了哪些文件、请重点看哪」，评审人才有的放矢，Codex 的改动也能被团队真正把关。
一个完整示例
你：git checkout -b feature/cli
Codex：（在分支里实现 cli 功能）
你：git add . && git commit -m "feat(cli): 实现命令行入口"
你：git push && 提 PR
同事：在 PR 里审查
评审通过 → 合并 → 删分支
Codex 的活，全程在分支里、走 PR、有记录。
main 新建 feature/cli 分支；让 Codex 在分支里实现 cli 命令，改完提交并推送、提 PR；在 PR 描述里写清「做了什么 / 改了哪些文件 / 请重点审哪」并让同事评审后合并。②怎么判断做对了：整个过程 main 分支始终保持稳定、Codex 的改动都落在 feature/cli 分支里、PR 里能看到清晰的提交信息和评审讨论、合并后 main 正常。③卡住了怎么办：如果 Codex 想直接在 main 上改，明确说「先 git checkout -b feature/cli 建分支再干活」；如果提交信息不规范，让 Codex 按 feat(scope): 描述 格式重写。常见坑：Codex 直接在主干上改，忘了分支
刚学分支隔离时，最容易犯的错是：你跟 Codex 说「做个功能」，它没意识到要开分支，直接在 main 上就改了。 等你看的时候，main 已经被它改得乱七八糟，半成品还混着好代码，回滚都不知道从哪下手。
避坑办法：把「开分支」当成对话的第一步，而不是默认它会自觉。每次开始新任务，先把它锁到分支：
先 git checkout -b feature/<功能名>，确认你在新分支上，
再开始实现。全程只在 feature 分支改，不许碰 main。
甚至可以让 Codex 在开场就自报「当前在哪个分支」：
开始前，先 git branch --show-current 确认你在 feature 分支。
确认在新分支后，再动手。
把「确认分支」变成默认动作，Codex 就很少会「越轨」到主干上。分支是 Codex 安全网的第一层，这层网得你自己拉好。
小结
- 分支隔离：Codex 在独立分支干活，主干稳定
- 流程：建分支 → 干活 → 提交 → PR → 评审 → 合并
- 提交信息写清楚，让改动可追溯
- PR 是让 AI 改动可审查的关键
下一节，讲 Codex 与 Git 命令的协同。