一、现象：死链又“回来”了

某天打开网站，发现顶部导航里又冒出 4 个 pxid 主题站入口（黑橙 / 红黑 / 黄传 / 原版）。可我记得早该处理掉——它们指向的子站页面从头到尾都没建过，是纯纯的死链（点过去 404）。“又回来”这个错觉，本身就是 bug 的信号。

本文结论

删干净不是终点。真正的问题是一套没人强制的部署纪律，让“已删除”随时可能被旧版本覆盖回来。

二、排查：它们从没被 git 删过

顺着 git 历史追，发现这 4 行导航是某次提交加进 index.html 的，在 git 里从来没被删过。每一次部署都是把 git 里的版本原样推上服务器，所以它们必然在。它们“消失又出现”，是因为有人曾直接在服务器（ECS）上改过文件，被后来的 git 部署又覆盖回来——这正是“单一真相源”铁律诞生的由来。

git 是真相源，ECS 只是它编译出的产物。你不会去改 .exe 再同步回 .c。

三、根因：两个写入源在打架

整件事是一条根因的不同表现：项目长期存在“ECS 直改”和“git 部署”两个写入源并行，而“单一真相源”只是纸面铁律，没有被工具强制。

现象本质
7-24 事故：pxid 页被冲掉ECS-only 改动，被 git 部署覆盖
本次“死链又回来”git 里一直有这 4 行；有人直改 ECS 造成错觉
我这边违规（没先 fetch、绕脚本直传）本机 git 凭证坏掉 → 正规脚本跑不通 → 为赶工走捷径

关键洞察

流程违规往往不是“人懒”，而是“工具链故障逼出来的”。凭证坑不根治，下次还会有人为赶工绕过脚本。

四、不是 git 的锅，是“没强制”的锅

很多人一听“git 又出问题”，就觉得是 git 难用。其实git 的机制恰恰是对的：删除一旦进历史就永久，不会被别人更新自动复活。要让死链回来，必须有人主动重写加回并 commit——那会被历史审查到。

真正脆弱的是“靠人和 AI 自觉”来守住纪律。一旦环境配置出错（比如本机 git remote 被全局规则改成了无凭证的 HTTPS），正规部署命令跑不通，捷径就出现了。

五、怎么解决：从纸面到机器强制

共识层已经做了两件事：把规则写成仓库内的 RULES.md，以及根治本机凭证（remote 锁 SSH、删掉错误的 insteadOf）。但治本在“机器强制”，不靠自觉：

Adeploy.sh 加护栏

部署前强制 fetch + 校验本地 = origin/main，有未提交改动直接失败。把“先 fetch / 先 commit / 走脚本”从口头纪律变成脚本硬挡。

B部署前死链检查

扫描所有站内链接，目标文件不存在就阻断部署。直接灭掉“指向不存在子站”这类死链上线。

CECS↔git 漂移监控

定期比对，发现 ECS 有 git 没有的改动就告警 / 自动覆盖。根治“有人直改 ECS”这一最古老的根因。

六、写进 git 的 RULES.md

最终我们把维护纪律固化进仓库根部的 RULES.md（已 commit、所有人 pull 可见），五条铁律：

# 铁律速记
1. git 是唯一真相源，ECS 只是镜像
2. 改前先 fetch + 看日志，确认基线最新
3. 改完 commit → ./deploy.sh（先 pull 再推）
4. 禁止直改 ECS、禁止绕脚本直传
5. 删除进历史即永久，别去 ECS 直接删

七、留一句话

如果只删 ECS，下次部署就会被 git 版本覆盖回来——所以“在 git 里删”不是多余，是保证删除不被覆盖的唯一可靠手段。工具可以修，纪律要写进代码才作数。

git部署单一真相源ECS工作流复盘
返回随笔