本篇会在 Codex 动文件前记录一份 Git 基线。最终产物包括仓库路径、当前分支、最近提交、未提交文件清单和本次允许修改的路径。任务结束后，你可以拿这份记录判断哪些变化原本就存在。
前置条件
项目需要已经处于 Git 仓库中。若应用提示创建仓库，而你不清楚团队做法，先停下询问，不要为了使用审查面板临时初始化。准备一项范围很小的任务，并暂时要求 Codex 只读检查。
打开正确项目的集成终端。终端属于当前项目或工作目录，仍要亲自核对路径。多个名字相似的副本最容易造成误改。
第一步记录仓库与分支
运行下面两条只读命令。
git status --short --branch
git log -1 --oneline
第一条会显示分支和工作区变化，第二条给出最近一次提交。把输出保留在聊天或任务笔记里。可见结果至少包括分支名或当前 HEAD 状态，以及一行提交编号和说明。
若命令报告当前目录不是 Git 仓库，先检查项目路径。不要继续运行提交、撤回或清理命令。
第二步认领已有改动
git status --short --branch 出现文件时，逐个确认来源。你自己正在写的内容要明确标成保留。来源不明的文件先不动，可以询问同事或查看差异。审查面板显示的是整个仓库状态，里面会混合 Codex、你和其他工具留下的变化。
让 Codex 只读汇报也很有用。
先不要修改。请列出当前分支、未提交文件和最近提交。把现有改动视为需要保留，等我确认本次允许修改的文件。
第三步写下本次允许范围
基线确认后，把允许修改的路径放进任务提示。比如只允许 src/help.md，并要求完成后再次列出 Git 状态。现有改动与目标文件重叠时，要先处理清楚。可以保存自己的工作，或缩小任务换一份文件。不要让 Codex 猜哪几行属于谁。
干净工作区会显示没有未提交变化。工作区不干净也能继续小任务，前提是来源清楚、保留项写明，并且验收时能分开看差异。
第四步保存基线再允许编辑
把路径、分支、提交和文件清单合并成一段短记录，然后明确说可以开始。任务结束后重复同一条状态命令，把新增变化与基线对照。这里先学会起点检查，分支同步、Worktree 和 rebase 留到后续 Git 教程。
一份合格基线能回答什么
基线应让后来查看的人回答四个问题。任务从哪个仓库和分支开始，最近提交是什么，开始前已有哪几份改动，这次允许碰哪些路径。可以把记录写成短句，随后附上两条命令输出，避免只留下无法核对的口头描述。
若状态显示 src/header.css 已修改，而本次任务只允许写 src/help.md，就把前者标成保留。任务结束后再次运行同一状态命令，新增文件应集中在允许范围。若 src/header.css 也发生新变化，暂停并查看差异，不要凭最终文件判断哪一部分属于谁。
工作区干净时也要留记录。空的未提交清单本身就是证据，它说明后续出现的变化发生在任务开始以后。保存这份起点，再允许 Codex 编辑，出了偏差才有可靠的比较对象。
基线记录不需要包含整段提交历史。最近一条提交、当前分支和状态清单足以支持这次小任务。若团队另给了明确基准，把它一并写入记录并核对是否一致。发现不一致时先停下询问，保留现状，不在这篇入门流程里自行拉取、切换或重写历史。
常见失败与恢复
看到大量陌生改动时，停止编辑并确认来源。不要运行批量撤回。分支名与预期不同，先回项目侧栏核对目录和聊天。最近提交与团队提供的基准不一致时，记录差异并询问负责人，暂时不要自行同步远端。
Codex 已经开始改动才想起检查基线，可以暂停任务，先保存当前状态和工具记录。此时已无法仅凭最终 Git 状态完全还原起点，需要结合最近一轮操作逐项确认。
完成检查
基线中有仓库路径、分支、最近提交和未提交文件。每份已有改动都有明确处置，任务提示也写明允许路径。到这一步再让 Codex 编辑，任务结束后便能复查新增差异。
