别让代码变成灾难现场
还记得6年前,我第一次给客户做企业站，用FTP上传改代码，结果改错了CSS，整个页面崩了三天，客户骂娘，我熬夜重写，最后发现原来有Git这种神器，如果你还在用“Ctrl+C复制整个项目文件夹打压缩包”的方式管理代码，你离“删库跑路”只差一次手滑。
为什么你的网站需要Git？三个血泪教训
教训1：域名解析改崩后的“回滚”噩梦
有一次我改Nginx配置，手误删了域名指向，网站直接404，因为没有版本控制，只能凭记忆拼凑以前的配置文件，花了4小时才恢复，如果用Git，一条git checkout -- nginx.conf就能回到半小时前的状态。
Git入门教程，一个建站老手的版本控制避坑指南—从踩坑到封神
教训2：SSL证书更新时，别手动改目录
当你的网站挂上SSL后，证书续签脚本经常需要修改www目录下某些文件，有次我直接用rm -rf删了不该删的隐藏文件，结果证书验证失败，整站HTTPS变灰，当时如果项目放在Git仓库里，git stash加git pull就能无损恢复。
教训3：给服务器装程序别犯“无脑复制”病
新手常犯的错误：从网上复制粘贴WordPress主题或插件直接覆盖服务器文件，结果误带了后门代码，或者修改了.gitignore里的秘钥文件，学会Git分支管理后，我会在本地稳妥测试，再合并到生产分支。
Git部署流程图（我亲测过的方案）
方案A：本地开发 → 代码推送 → 服务器自动拉取
# 服务器端（以CentOS为例） cd /var/www/html git init git remote add origin https://你的Git仓库地址 git checkout -b production # 设置钩子，每次push后自动拉取 cd .git/hooks touch post-receive chmod +x post-receive # 写入：cd /var/www/html && git pull origin production
踩坑点：
- 一定要为仓库设置
webhook或CI/CD，否则手动敲git pull太容易忘记。 - 生产分支必须加保护规则,禁止直接push，我用
git branch -m main production重命名，配合GitHub的分支保护规则，避免误操作。
方案B：利用Git文件覆盖解决“域名配置冲突”
曾帮一个朋友解决bug：他的服务器绑定了3个站点，配置文件总被另一个项目覆盖，方案：为每个站点创建独立Git仓库，/etc/nginx/sites-enabled/下的链接指向不同仓库的配置文件版本，然后用.gitignore忽略敏感路径。
SSL证书与Git的“隐形坑”
坑1：证书私钥别乱提交
第一次用Let's Encrypt时，我直接把/etc/letsencrypt/live/域名/private.pem写进git add -A，差点把私钥推上公网，正确做法：在.gitignore里写上*.pem、*.key，且服务器端用环境变量存储路径。
坑2：证书续签时的冲突
当certbot自动续签证书时，它会修改/etc/nginx/sites-enabled/下的配置文件，如果这个目录是Git仓库的一部分，就会产生无法追踪的修改，我通常把Nginx配置模板放在仓库里，用sed或envsubst替换变量，服务器端使用cron定时从模板生成实际配置。
域名解析与Git协作的“野路子”
我曾经给客户迁移域名,原本在A记录下挂了多个子域名，用Git管理DNS配置的思路：
- 把DNS解析记录整理成JSON格式,存进仓库。
- 写个脚本读取JSON,调用Cloudflare API自动修改记录。
- 每次变更先push到Git,再触发脚本生效。
这样谁改了哪个域名，什么时间改的，回溯时一目了然。
提醒：别把域名注册商的管理面板密码写进任何文件！可以用git-secret或gpg加密敏感配置。
长期维护建议：让Git成为你的“后悔药”
每天下班前强制做一次commit
哪怕只是“修正typo”这样的鬼话，也要留下记录，我有个习惯：每次修改Nginx或SSL配置前，先git stash保存状态，改完测试没问题再git stash pop，如果改崩了，直接git checkout .恢复。
给服务器定期打补丁时切分支
遇到操作系统安全更新或PHP版本升级，先在本地分支测试，镜像环境跑一遍，没问题再合并到production，有一次我手贱升级了Nginx，忘了改默认配置，结果整个服务器配置被覆盖，幸好有Git回滚。
使用git blame查历史
有次网站突然变慢，我git blame /etc/nginx/nginx.conf发现同事上周加了一条worker_connections 128;（默认1024），直接找到责任人并改回。
备份不等于版本控制
很多老站长用每日压缩包备份，但归档占空间又难检索，我改用Git+LFS管理大文件（比如图片、备份数据库），核心配置文件用.gitignore排除敏感信息后，仓库体积控制在10MB以内。
最后一个建议：不管项目多小，第一时间初始化Git
哪怕只是给个人博客写三篇随笔，也要先git init，某次服务器崩溃，我靠git log找到了修改前的数据库结构，省去一周重写。
终极避坑清单（打印贴墙上）
- 永远不要用root账号操作Git仓库,易误删
- 生产服务器
/var/www/html下不要有.git文件夹，用裸仓库分离（git init --bare） - 数据库备份单独管理,别塞进Git仓库（除非用LFS）
- 域名和SSL配置变更后,先
git diff检查，再git commit - 每月第一周：
git gc清理仓库垃圾 - 遇到“权限不足”时，先检查
chown，再检查.git文件的权限
Git不是银弹,但它能让你在服务器崩溃时，至少有一个“原路返回”的导航系统，我从只会git add . && git commit -m "update"的菜鸟，到现在用Git管理整站部署、CI/CD和配置回溯，省下的时间至少够读两本小说了，至少，我再也不用对着404页面抓耳挠腮了。
