说到 Git 自动部署，这确实是个能极大提高开发效率的好东西。记得我刚接触这个概念时还在想：”每次改完代码都要手动去服务器上拉取更新，这也太麻烦了吧？”后来学会了自动部署，才明白什么叫做”一劳永逸”。想要实现这个功能，其实有很多种方式，但核心思路都是一样的 – 当 Git 仓库有新的推送时，自动触发部署脚本。
最简单的 Git Hook 方案
最直接的方法是在服务器上配置 Git 的 post-receive 钩子。这个方案虽然原始，但出问题的几率最小。我自己的博客就是用的这个方法，在服务器的裸仓库里放置一个 post-receive 钩子脚本，每当本地 push 代码后，服务器会自动执行部署操作。
#!/bin/bash
TARGET="/var/www/myblog"
GIT_DIR="/opt/git/myblog.git"
BRANCH="main"
while read oldrev newrev ref
do
if [[ $ref = refs/heads/$BRANCH ]];
then
echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
else
echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed."
fi
done更加现代的 CI/CD 方案
如果你追求更专业的解决方案，可以考虑集成 CI/CD 工具。GitHub Actions 就是个很好的选择，配置起来相当直观。我最近在一个项目中尝试过，只需要在仓库里添加一个 .github/workflows/deploy.yml 文件，不到 50 行配置就能实现自动测试和部署。
讲真，看到测试通过后系统自动把代码部署到服务器的那个瞬间，你会感觉前期的配置工作都值了。不过要提醒一点，CI/CD 方案通常需要你对 YAML 配置有一定了解，如果出问题，调试起来会比简单的 Git Hook 麻烦一些。
一些实用的建议
在实践中我总结出几个小技巧：首先，记得给部署脚本加上错误处理，否则一旦部署失败就很难定位问题；其次，最好在部署前做个备份，万一新代码有问题还能快速回滚；最后，如果是生产环境，强烈建议先部署到测试环境验证，再用 “蓝绿部署” 的方式切换。
自动部署看起来高大上，但实际上门槛并不高。我见过不少开发者因为担心配置复杂而不敢尝试，其实只需要花一个下午的时间，就能把这项工作自动化，之后的每次部署都能节省大把时间，这投资回报率简直不要太高！
评论