如何在GitLab/GitHub托管仓库实现pre-receive钩子？

核心思路 #

由于GitHub/GitLab等云托管服务不支持自定义pre-receive服务器端钩子，需结合平台原生能力或轻量中间层实现等效校验逻辑，同时满足云托管保留、SSH/HTTPS双支持的要求。

方案1：平台原生CI/CD前置校验（推荐） #

• 实现逻辑：借助GitHub Actions或GitLab CI/CD，在代码推送后触发校验，通过分支保护规则强制所有修改走PR/MR流程，未通过校验的PR/MR无法合并。
• 操作步骤：
  1. 在仓库根目录添加CI配置文件（如.github/workflows/pre-push-check.yml或.gitlab-ci.yml）。
  2. 编写校验脚本（检查提交格式、代码规范、敏感信息等），作为CI流程的首个执行步骤。
  3. 配置平台分支保护：禁止直接推送到主分支，要求PR/MR必须通过CI校验才能合并。
• 优势：
  • 完全基于云托管平台能力，无需额外部署服务器。
  • 兼容SSH/HTTPS推送，任何方式的代码提交都会触发校验。
  • 权限控制与平台原生体系一致，不会出现作者名丢失、权限绕过问题。
• 局限性：无法做到严格的「推送前阻止」，而是「推送后阻止合并」，但分支保护可强制校验前置。

方案2：轻量Git代理层+平台API校验 #

• 实现逻辑：部署一个轻量代理服务作为用户与云托管仓库的中间层，拦截所有推送请求，执行自定义pre-receive校验后，再以用户身份转发到云托管仓库。
• 解决原镜像方案的痛点：
  • 保留作者信息：代理使用git push --mirror推送，或通过环境变量GIT_COMMITTER_NAME/GIT_COMMITTER_EMAIL传递用户身份，确保提交作者信息不丢失。
  • 权限控制：代理集成公司身份认证系统（LDAP/SSO），同时调用云托管平台API校验用户对目标仓库的实际权限，避免未授权推送。
• SSH/HTTPS支持：代理同时提供SSH和HTTPS服务，用户只需将远程仓库地址改为代理地址即可，无需调整本地Git操作逻辑。
• 优势：实现真正的「推送前阻止」，完全等效pre-receive钩子逻辑；兼容所有推送方式。
• 局限性：需部署和维护轻量代理服务，但无需搭建完整Git服务器，仅作转发校验用。

方案3：统一管理全局pre-commit钩子（规避冲突） #

• 实现逻辑：通过公司统一配置工具强制部署全局pre-commit钩子，同时解决用户自有钩子冲突问题：
  1. 使用pre-commit框架的多钩子机制，将公司级钩子设为独立阶段，与用户自有钩子共存。
  2. 编写跨平台校验脚本（如Python），兼容Mac/Linux/Windows及不同Git CLI版本。
  3. 通过组策略（Windows）、配置管理工具（Ansible/SaltStack）或内部Git初始化脚本，自动为所有工作站配置全局钩子并设置优先级。
• 优势：无需服务器部署，完全在客户端实现校验。
• 局限性：存在用户手动禁用钩子的风险，适合合规要求非极端严格的场景。

方案对比 #

内容的提问来源于stack exchange，提问作者Idan