2026-10-17 · Codex 教程 ⑧ · 计划与审查
先写清
再动手
改代码之前，最危险的动作往往不是“改错”，而是“先同步一下”。 我们这次先查清仓库指针和工作区的关系，再决定动不动它。
准备补这五篇文章时，git -C dola status --short --branch 给出两个看似矛盾的消息：
分支显示 main...origin/main [behind 6]，HEAD 是 ecea656；
但工作区里有一堆未提交改动，还有几篇未跟踪的新文章。
按直觉，应该先 pull 或 reset。可那样做，很可能把正在写的稿子覆盖掉。
我们没有动。先读发布说明：站点源码目录不是发布入口，真正推送的是
.dola-deploy/repo 里的镜像克隆，脚本只允许快进。
再逐个比对：镜像 HEAD 是 67c14b5，镜像里的 32 个文件在工作区全部存在，
逐字哈希一致；其中 23 个属于本地 HEAD，另外 9 个尚未提交。
结论是：本地 HEAD 指针落后，但工作区内容已经等于远端；
指针旧不等于文件旧。
三样东西，不能混成一个 pull
| 看到的东西 | 当时的值 | 说明 |
|---|---|---|
| 站点源码 HEAD | ecea656 |
本地分支指针，落后 6 个提交 |
| 镜像 HEAD | 67c14b5 |
部署脚本真正推送的远端镜像 |
| 工作区文件 | 32 个镜像文件 | 全部存在且逐字一致（23 跟踪 / 9 未提交） |
指针、工作区、远端是三样东西。指针落后可以只是“没 fetch”，
工作区却可能已经是最新内容；反过来，指针最新也不保证文件没被人改过。
在脏工作区里执行 reset、checkout 或 pull，
保护不了任何一方。
计划模式：先写清要动什么
这次的计划只有四步：列出要新增的五个页面；核对每篇的素材和链接；
只改 notes.html、sitemap.xml、路线图和一处连载尾注；
最后查结构和链接。计划写在前面，改的时候就不会一边写一边改范围。
计划模式的价值不是“多一步”，而是把“我打算动什么”变成可以先审的东西。
看 diff，不看“我觉得没问题”
改完以后看三样：git status --short 确认只多了预期的文件；
git diff --stat 确认索引文件的改动量；再用脚本检查新页面的标题、
canonical、相对链接和字符数。
发布脚本的判断更硬：线上文件与本地文件忽略空白后哈希一致，才算成功； 命令退出码不算证据。这条规矩和 ② 把红线写成代码 里说的是同一件事。
先读状态，再比对内容；确实需要同步，也在镜像里做。 工作区里的未提交文件，可能正是别人正在写的东西。
结论
先写清要改什么，再改；改完看 diff 和测试；要发布，再看线上逐字结果。 慢的是前面几分钟，省下的是返工。
《Codex 教程》连载：① 总纲 · ② 把红线写成代码 · ③ 记忆放在哪里 · ④ 守收件箱，不碰发送键 · ⑤ 工具链不是装得越多越好 · ⑥ 让它「看」视频 · ⑦ Skills 不是插件市场 · ⑧ 先写清，再动手 —— 下一篇：四道门，决定哪些事可以自己跑。 回到笔记