首页/开发/Git 与协作速查/服务端钩子与策略落地
进阶与大仓实践69 条

服务端钩子与策略落地

pre-receive、update、post-receive 在服务端仓库执行,无法被客户端绕过,适合做强制策略(拒绝大文件、校验提交格式、触发通知)。

Git 与协作速查开发更新于 2026-10-13

服务端钩子是什么

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 的服务端钩子在管理界面配置,直接改服务器文件可能被平台覆盖。

易错点

  • 在服务端钩子里做重活:校验或通知耗时会让所有人的推送一起变慢,耗时操作改为异步队列
  • 托管平台覆盖手工改动:直接往服务器钩子目录塞文件可能被平台升级重写,改用平台提供的配置机制
  • 报错信息不清:贡献者只看到推送被拒却不知道如何修,报错里要给原因与正确示例
  • 校验逻辑没有逃生口:紧急发布被格式校验挡住时应有管理员豁免通道,并记录豁免原因

数据来源与参考

  • Git 官方文档:githooks(服务端钩子)
  • Pro Git 2nd Edition · 8.4 使用强制策略的示例
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌