shell脚本配合git实现自动化部署的核心是将拉代码、停服务、打包、重启四步操作流程化、可靠化。需提前配置git、权限、路径及构建工具，脚本按顺序执行停服、拉取、构建、启服，并加入错误退出、日志记录、备份和变量管理等健壮性措施。
用 Shell 脚本配合 Git 实现自动化部署，核心是把人工操作（拉代码、停服务、打包、重启）变成可重复执行的一连串命令。关键不在写得多复杂，而在流程可靠、容错清晰、权限和路径明确。
基础环境必须提前配好
脚本本身不负责装环境，但运行前得确保：
- Git 已安装并能正常 clone/pull（建议配置 SSH 免密或 credential store）
- 项目目录存在且脚本有读写权限（如
/var/www/myapp） - 若需编译（如 Maven/Gradle），对应工具已安装、环境变量生效
- 运行脚本的用户对目标目录、进程有操作权限（常需
chown -R deploy:deploy /var/www/myapp）
脚本主体要覆盖四个关键动作
一个最小可用部署脚本通常包含以下逻辑块，顺序不能乱：
-
停旧服务：用
ps -ef | grep找进程 PID，先发 SIGTERM（kill -15），等 2 秒再检查，残留则用kill -9 -
拉新代码：
cd /path/to/repo && git pull；建议加判断，比如git status --porcelain检查是否有未提交修改，避免冲突中断 -
构建或准备运行包：Java 项目执行
mvn clean package -Dmaven.test.skip=true；前端项目执行npm install && npm run build；静态站点可直接跳过 -
启新服务：用
nohup java -jar xxx.jar > app.log 2>&1 &后台启动；或用 systemd 管理更稳妥（脚本里可调systemctl restart myapp）
安全与健壮性不能省略
生产环境脚本不是跑通就行，得防错、留痕、可追溯：
- 每步加
set -e，任一命令失败立即退出，避免“半截部署” - 关键操作输出重定向到日志，如
git pull >> deploy.log 2>&1 - 备份旧配置文件再更新，例如
cp config.yml config.yml.bak，更新后用diff判断是否需恢复 - 避免硬编码路径和项目名，改用变量定义：
APP_DIR="/opt/myapp"; JAR_NAME="app.jar"
进阶可对接 Git Hooks 或 CI 触发
真正自动化不止靠手动运行脚本：
- 在远程 Git 仓库启用
post-receive钩子，收到 push 后自动 ssh 到服务器执行部署脚本 - 本地提交后用
git commit -m "deploy: update api" && git push，配合钩子即触发上线 - 若用 Jenkins/GitLab CI，把上述脚本内容作为 pipeline 的 shell 步骤，还能加测试、通知等环节
