正文

Git入门教程，一个建站老手的版本控制避坑指南—从踩坑到封神

云上阿飞
云上阿飞 V管理员 /53阅读/3评论
0723
文章最后更新时间2026年07月23日，若文章内容或图片失效，请留言反馈！

别让代码变成灾难现场

还记得6年前,我第一次给客户做企业站，用FTP上传改代码，结果改错了CSS，整个页面崩了三天，客户骂娘，我熬夜重写，最后发现原来有Git这种神器，如果你还在用“Ctrl+C复制整个项目文件夹打压缩包”的方式管理代码，你离“删库跑路”只差一次手滑。

为什么你的网站需要Git？三个血泪教训

教训1：域名解析改崩后的“回滚”噩梦
有一次我改Nginx配置，手误删了域名指向，网站直接404，因为没有版本控制，只能凭记忆拼凑以前的配置文件，花了4小时才恢复，如果用Git，一条git checkout -- nginx.conf就能回到半小时前的状态。

Git入门教程，一个建站老手的版本控制避坑指南—从踩坑到封神

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配置的思路：

  1. 把DNS解析记录整理成JSON格式,存进仓库。
  2. 写个脚本读取JSON,调用Cloudflare API自动修改记录。
  3. 每次变更先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页面抓耳挠腮了。