服务端钩子是什么
pre-receive、update、post-receive 是在服务端仓库执行的钩子:它们无法被客户端跳过,适合落地强制策略——拒绝超大文件、校验提交信息格式、合并后触发通知或部署。出错的钩子会拒绝整次推送,因此报错信息必须写清楚,否则贡献者只看到推送被拒而无从下手。
基本信息
| pre-receive | 整次推送开始时执行一次,适合整体校验 |
|---|---|
| update | 每个被推送的引用各执行一次,适合逐分支规则 |
| post-receive | 接收完成后执行,适合通知、CI 触发与部署 |
| 特点 | 客户端不可绕过;出错拒绝整次推送 |
| 平台差异 | GitLab 由管理员配置服务端钩子;GitHub 侧用 CI 与分支保护实现同等约束 |
典型使用场景
- 提交信息规范:不合法格式直接拒收,历史消息质量有保证
- 大文件拦截:超限对象在入口就被拒绝,避免事后清理历史
- 签名与署名检查:强制签名提交或签章才能推
- 镜像与备份:post-receive 触发同步或归档任务
- 权限兜底:保护分支之外的额外限制在服务端统一执行
pre-receive 示意
pre-receive 示意
#!/bin/sh
# 在服务端仓库的钩子目录中,从标准输入读入引用变更
while read old new ref; do
git log --format='%s' $old..$new | grep -qE '^(feat|fix|docs|chore)(\(.+\))?!?: ' || {
echo "提交信息不符合规范,示例:feat(x): 描述" >&2 # 明确报错信息
exit 1 # 拒绝整次推送
}
done三种钩子对照
| 钩子 | 触发次数 | 典型用途 |
|---|---|---|
| pre-receive | 每次推送一次 | 整体策略校验、对象数量与大小 |
| update | 每个引用各一次 | 按分支的精细规则 |
| post-receive | 推送完成后 | 通知、部署、镜像同步 |
强策略要给出可操作的报错:说明原因、给出正确格式示例,否则支持成本会很高。
托管平台的仓库目录通常由平台维护:GitLab 的服务端钩子在管理界面配置,直接改服务器文件可能被平台覆盖。