Codex 配合 Git 的安全工作流：分支、提交与回滚

Git 是 Codex 工作流的重要安全网，但只有在分支清楚、提交粒度合理并且用户改动受到保护时才真正有效。不要把“有 Git”理解成可以随意删除或覆盖，因为未提交文件、外部数据和生产操作并不一定能通过 Git 恢复。

## 开始前检查工作区

先查看当前分支和工作区状态，识别哪些修改属于用户已有工作。未经确认，不要重置、覆盖或清理这些文件。若任务会触及相同文件，应先说明冲突并决定如何隔离。

一个安全起点通常包括：目标分支明确、现有改动已提交或妥善保留、远程状态已了解、构建基线可以运行。

## 为任务建立清晰边界

复杂任务可以使用独立分支或工作树。分支名称应描述目标，而不是使用含糊的 test 或 temp。并行任务必须避免同时修改同一文件；如果不可避免，应先确定合并顺序和负责人。

## 小步提交的价值

把调查性重构、功能实现、测试和格式化混成一个大提交，会让审查和回滚都变困难。更好的方式是每个提交表达一个完整意图，并在提交前运行对应验证。

提交信息应说明为什么改，而不只是“update files”。但是否创建提交应由用户授权，代理不应默认替用户提交或推送远程。

## 回滚前先判断对象

- 未提交的代理改动：只恢复明确属于本次任务的文件。 - 用户已有改动：不得擅自丢弃，应先备份或协商。 - 已提交但未推送：可选择反向提交或在确认后调整历史。 - 已进入共享分支：优先使用可追踪的反向提交，避免破坏他人历史。

不要在目标不明确时运行递归清理、硬重置或覆盖检出。任何破坏性命令都应先解析确切路径和影响范围。

## 合并前检查

1. 查看完整 diff 和文件列表。 2. 确认没有密钥、日志、构建产物或本地配置。 3. 运行相关测试与构建。 4. 检查提交是否只包含当前任务。 5. 记录部署后的回滚入口。

## Git 不能替代的保护

数据库写入、外部 API 调用、云资源修改和服务器文件并不一定在仓库中。涉及这些操作时，需要单独备份、审计日志和回滚方案。安全工作流的核心不是命令数量，而是每一步的归属、证据和恢复路径都清楚。