Git如何实现开发环境一键部署_Git钩子hooks自动化实战

### 先说结论：用 `post-receive` 钩子 + bare 仓库，是目前最轻量、最可控、也最容易出问题的“一键部署”方案。别去折腾 `post-update`，它在远程推送场景下根本不管用。这套方案行不行，全看几个关键细节有没有到位。

先直接给结论：用 `post-receive` 钩子配合 bare 仓库，确实是最轻量、最可控的一键部署方式，但也正是因为它足够“原始”，所以最容易踩坑。需要特别注意的是，别再碰 `post-update`，它压根儿不适合远程推送的场景。

为什么必须用 bare 仓库？git init --bare 不是可选项

裸仓库的特殊之处在于它没有工作目录，只存 Git 对象和引用——说白了，它就是为远程协作量身打造的。别小看这个命令，如果你在服务器上用 `git init`（没加 `--bare`），那么 `.git/hooks/post-receive` 这个文件根本不会被 Git 调用——因为 `post-receive` 只在接收推送的 bare 仓库中生效。 经常遇到的坑包括： - **错误现象**：`git push` 返回成功，但服务器上的代码纹丝不动，`post-receive` 完全静默 - **检查方法**：赶紧检查一下仓库的路径 —— `ls -la /path/to/repo/.git`，如果能看到 `HEAD`、`index`、`objects/` 这些目录，但看不到 `worktrees/` 或项目文件，那恭喜你，这是 bare 仓库 - **补救操作**：如果你已经搞了个非 bare 仓库，别慌：`git clone --bare /old/repo /new/bare.git && rm -rf /old/repo`，然后再把钩子脚本重新配一遍

post-receive 脚本里必须写绝对路径和显式解释器

这个问题的根源在于，SSH 登录用户的环境变量并不可靠。你永远不知道 `git` 命令会不会找不到，`cd ..` 会不会进错目录，更糟糕的是脚本可能直接退出连个报错都没有。 正确的做法是： - 脚本开头必须是 `#!/bin/bash`，别用 `#!/usr/bin/env bash`，省得出幺蛾子 - 所有命令都用绝对路径：`/usr/bin/git`、`/bin/chown`、`/usr/bin/rsync`，一个都不能少 - 切换目录前先确认路径：`cd /var/www/myapp || exit 1`，别信 `cd ..` 这种偷懒写法 - 还有个常见陷阱：`git checkout -f` 失败却不给提示——解决方案是加 `set -e`，让脚本遇到错误立刻终止，好歹你能看到错误信息

权限问题比逻辑错误更常导致部署失败

这一点很多人容易忽略：Git 钩子是以 SSH 登录用户的身份在执行，但你的 Web 服务器（比如 Nginx 或 Apache）通常用 `www` 或 `nginx` 用户来读文件。如果钩子执行后没改文件的所有权，那网站会直接 500 或 403。 典型的错误是收到这样的提示：`remote: fatal: unable to mkdir 'xxx': Permission denied` 需要记住的关键操作（以宝塔面板为例）：`/bin/chown -R www:www /www/wwwroot/my-site` 但有一点必须强调：千万别在脚本里用 `sudo`。如果 SSH 用户没配免密 sudo 权限，脚本会直接卡住不动；更别想着在钩子里切到 root 用户。 安全底线很清楚：部署用户（比如 `deployuser`）不能是 root，而且它的 home 目录不应该给其他用户写权限。

Webhook 替代方案更适合 GitHub/Gitee 私有库

如果你的代码托管在 Gitee 或自建的 GitLab，用 `post-receive` 需要开放 SSH 端口并且手动管理公钥，运维成本确实不低。相比之下，Webhook + 简单的 PHP 或 Python 接口更容易做审计和流量限制。 几个必须注意的细节： - 必须加校验：用 `$_GET['token']` 或者 `X-Hub-Signature-256` 请求头，不然任何人都能触发你的部署脚本 - Nginx 那边需要调整限制：`client_max_body_size 10M`、`fastcgi_read_timeout 300` - 别把 Webhook 脚本直接放在 Web 可访问的路径下——用 `include` 或者 CLI 方式调用实际的部署逻辑更安全 - 还有一个更稳妥的 Plan B：用宝塔的“计划任务”每 3 分钟执行一次 `cd /path && /usr/bin/git pull origin main --ff-only`，失败日志清清楚楚 说真的，写脚本从来不是最麻烦的事。真正让人头疼的是每次 `git push` 之后都得盯着日志看哪一行没输出——说到底，无非是少了一个 `2>&1` 的重定向，或者 `chown` 的时候漏掉了某个子目录。