在脏工作区中划清 add、commit、push 与 deploy

测试全绿，git status 却让人不敢按下发布

列表里有你的修复，也有用户写到一半的样式、一个不明生成文件和修改过的环境示例。最省事的做法似乎是全部 add，或者先清干净再来。

这两种省事都可能伤到别人。

脏工作区首先是一份所有权报告，不是清理命令的邀请。 这节课会把每项变化分成用户改动、任务改动、生成物和未知，再从中构建一份可解释的发布集合。

“工作区不干净”不是让你清空它的理由

多人或多任务共用工作区时，git status 可能同时包含：

• 用户原有未提交改动；
• 本轮实现产生的文件；
• 生成物或调试文件；
• 其他任务刚写入的变化。

安全交付不是让状态变干净，而是准确知道谁拥有每个变化、哪些属于发布集合、哪些必须排除。

本节只分析模拟输出，不会连接真实仓库或生产。

第一步：给每个文件标所有权

打开 dirty-worktree-simulation.md，把状态中的文件分为：

类别	处理
本轮明确修改	进入候选发布集合
用户已有修改	保留，不覆盖、不暂存
生成物或临时文件	确认来源后排除或清理
所有权不明	暂停，不猜

不要使用“全部 add 再说”。暂存区本身就是发布边界的一部分。

第二步：让 Codex 只读建立发布集合

只读检查模拟 git status、变更摘要和 release brief。
不要执行 add、commit、checkout、reset、clean、push 或 deploy。

请输出：
1. 建议进入本轮发布的文件及理由；
2. 明确排除的用户改动；
3. 所有权不明或需要我确认的文件；
4. 代码、数据、配置、文档和生成资产之间的依赖；
5. 发布前需要运行的检查；
6. 每个外部动作需要的单独授权。

合格结果不会把“测试截图”“数据库 migration”“环境变量”当成无关附件。发布集合要覆盖行为真正依赖的所有部分。

第三步：区分四个动作

动作	改变什么	常见误解
add	选择进入暂存区的文件	不是“保存文件”
commit	在本地历史建立快照	不等于远程可见
push	改变远程分支	不等于生产上线
deploy	改变运行中的生产版本	构建成功不等于部署成功

用户说“修复”通常授权工作区内修改和验证；并不自动包含 commit、push 或 deploy。用户明确说“add、commit、deploy”时，也不能擅自补成 push。

第四步：设计精确暂存

在模拟题中写出你会暂存的显式路径，不执行命令：

git add app/content/... tests/... public/tutorial-assets/...

然后用两类检查复核：

git diff --cached --name-status
git diff --cached --check

第一条确认文件边界，第二条检查空白等基本问题。真正提交前还应阅读 staged diff，而不是只看文件名。

第五步：建立发布前证据

发布前至少分层：

1. 内容或单元测试；
2. 类型与静态检查；
3. 构建；
4. 与风险相称的浏览器验收；
5. migration、队列、环境变量等运行时依赖；
6. 发布命令的 dry run（平台支持时）。

记录完整命令、结果和未运行项。旧的绿灯不能证明当前暂存集合。

第六步：先写回退点，再部署

回退点必须具体：

当前生产版本：
候选提交：
数据是否向后兼容：
旧版本能否读取新数据：
回退命令或平台入口：
回退后检查：
不可逆动作：

如果 migration 破坏向后兼容，只回退代码可能让系统更坏。此时要先设计兼容迁移、备份和恢复演练，而不是把“可以重新部署旧 commit”当完整回退。

第七步：生产验证不能只看部署命令

部署成功后至少核对：

• 平台显示的新版本是否 100% 接流量；
• 生产 URL 是否返回成功；
• 本次变化的关键内容或行为是否出现；
• 旧版本不应出现的内容是否消失；
• 队列、定时任务、数据库绑定是否仍在；
• 日志中是否出现新的高频错误；
• 移动与桌面关键路径是否通过。

生产验证使用真实域名，不用本地截图冒充。

第八步：填写授权矩阵

在 release-record.md 写：

动作	目标	是否已授权	实际结果	可恢复方式
add	明确文件列表	是/否	暂存 diff	取消暂存
commit	本地分支	是/否	commit SHA	revert
push	远程分支	是/否	远程 SHA	revert/new commit
deploy	生产服务	是/否	version ID	回滚版本

未经授权的行保持“未执行”，不要为了表格完整而补做。

参考答案与事故反例

参考答案中故意留下一个用户改动和一个不明生成文件。若你的发布集合包含它们，回看所有权判断。

想象一个常见事故：使用 git add -A 把用户正在写的 .env.example 和未完成样式一起提交；测试仍通过，但生产出现错误配置。根因不是 Git 命令本身，而是发布集合没有先被建模和复核。

发布前先回答「这是谁的变化」

对当前 git status 逐行标注所有权和处理决定。归属不明的保持原样，不要为了得到一张干净截图而清除。

add、commit、push、migration 和 deploy 分开记录授权。发布越接近生产，越不能用一次全选替代判断。

完成检查

• 每个变化都有所有权和处理决定
• 暂存路径与发布集合完全一致
• staged diff 和当前验证来自同一状态
• add、commit、push、deploy 分别记录授权
• 回退点覆盖代码、数据和运行时依赖
• 生产验证使用真实版本和真实域名