第一次“裸奔”的代价
2017年，我接了一个企业官网优化的活，客户那边用的是WordPress，之前的程序员离职后留下一堆杂乱代码，连个版本控制都没有，我当时想，反正改几个页面、优化点性能,问题不大。
结果呢？我手动改了十几处文件，测试没问题，第二天客户说首页挂了，我远程登录一看——谁把config.php改乱了？我翻来覆去找不到改动记录，连是谁操作的都不知道，最后只能从本地的临时备份里恢复,损失了整整两天的工作量。
版本控制不只是Git提交—一个老站长的血泪史，从手动备份到自动化部署的觉悟
那是我第一次意识到：没有版本控制，你在服务器上敲的每一行代码,都是在悬崖边跳舞。
后来我给自己立了个规矩：任何建站项目，第一件事不是装后台、不是搞设计，而是建Git仓库，哪怕只是一个单页静态站,也得上版本控制。
用版本控制解决“服务器换机房”的噩梦
2021年有个客户，做电商的，原来的服务器在香港，为了提升国内访问速度，决定搬到阿里云，按理说，迁移数据、换DNS解析、调证书,流程清晰。
但问题出在代码上——客户说他们之前“有备份”，但那份备份是运维手动打包的.tar.gz文件，时间戳显示的是一周前，这一周里，产品页面改过三次，购物车功能也修补过，迁移完一测试，优惠券功能报错,排查了三天才发现是PHP版本不一致导致的函数弃用。
如果他们有版本控制，我只需要在旧服务器上打一个tag，比如20210613_release，然后在新服务器上git checkout就行，再配合composer.lock锁定依赖版本,PHP版本差异根本不会影响业务。
从那以后，我帮客户做服务器迁移，第一个步骤永远是：先确认他们有版本控制，如果没有，我宁可多花两天时间把代码库先整合到Git上，再做迁移，省时间，省预算,更省心。
SSL证书过期，差点让客户损失两万
这事发生在2022年，一个做教育产品的客户，网站用的是Let’s Encrypt的免费证书，每三个月续期一次，运维离职后，没人管这事，有一天我在后台看到SSL证书还剩15天，就顺手帮他们续了，结果续完后发现，网站的图片加载全部走HTTP,混合内容导致浏览器拦截。
我排查了很久才发现，问题出在之前有人手动修改过wp-config.php里的siteurl定义，写死了HTTP，版本控制一查，commit记录显示是半年前运维埋的坑，如果没有版本控制，我根本不知道是谁改的、什么时候改的、为什么改。
解决方案其实很简单：在版本控制中，所有敏感配置（如数据库密码、API密钥、站点URL）都通过环境变量或.env文件管理，不在代码里硬编码，然后用Git钩子或CI/CD流水线，自动检测证书过期、SSL配置是否正确。
建议各位：SSL证书到期前30天设个日历提醒，同时在版本控制的README里写清楚证书更新流程，别依赖人的记忆,要依赖系统和流程。
版本控制不只是Git，还有“人”的版本
我见过最离谱的案例：一个团队做网站，开发用Gitee，测试用SVN，生产靠FTP手动上传，三个版本，三个源头,谁也不认谁的。
有一次紧急修复一个安全漏洞，开发在Gitee上改了，测试说SVN上没看到，生产上被FTP覆盖了，最后修了一个漏洞,又续了三个漏洞。
我后来给他们提了一个“版本控制三原则”：
- 统一仓库：不管团队大小，只用一套版本控制系统（推荐Git），所有分支、tag、issue都在一个平台管理。
- 代码即部署：生产环境只能拉代码，不能上传代码，任何修改都要经过commit、review、merge、deploy四个步骤。
- 回滚机制：每次部署前，自动打tag，出问题一键回滚到上一个tag,而不是去FTP翻历史文件。
这三个原则,把他们的故障修复时间从平均8小时降到了40分钟。
长期维护建议：版本控制是“时间机器”
给所有建站的朋友一些接地气的建议：
- 从小做起：哪怕你只有一个个人博客，也git init一下，别嫌麻烦,你永远不知道明天会有什么坑。
- 注释要写人话：commit message别只写“fix bug”，写清楚“修复用户注册时邮箱校验失效”，三个月后回头看,你会感谢自己。
- 善用.gitignore：缓存文件、日志文件、敏感配置，不该提交的别提交，我一个朋友的服务器被黑，就是因为不小心把
.env文件提交到公开仓库了。 - 自动化部署：GitHub Actions、GitLab CI、甚至简单的Webhook + shell脚本，能自动就别手动，手动操作的每一步,都是潜在故障点。
- 定期演练回滚：隔三个月强制演练一次回滚流程,别等到出事了才现学。
版本控制不是技术选型，是职业习惯，是保护自己、保护客户、保护业务的最底层保障。
好记性不如烂笔头，烂笔头不如版本控制，从今天开始，给你的网站一个“时间机器”。
