启用pre-receive服务器钩子，实现推送至dev分支前需PR/MR审批

核心结论 #

pre-receive钩子无法原生支持“推送前通知审批人并等待批准”的完整流程，但可以结合外部工具勉强实现，不过更推荐用GitLab原生的Merge Request（MR）流程来满足需求。

为什么pre-receive原生做不到？ #

• pre-receive是Git服务器端的同步钩子：它在推送内容抵达服务器后、写入仓库前触发，必须等待脚本执行完毕，Git才会决定是否允许推送。如果要在这里等待审批，意味着推送进程会一直阻塞，直到收到审批信号——这会导致推送会话长时间挂起，容易因网络中断、服务器资源耗尽等问题失败。
• GitLab的架构不支持这种长时间阻塞的钩子：官方设计中，pre-receive钩子仅用于快速检查（比如代码格式、提交规范），而非异步审批类的复杂逻辑，强行使用会破坏GitLab的正常工作流。

若硬要基于pre-receive实现，可行思路（不推荐） #

如果必须用pre-receive钩子来做，需要结合内部审批系统，步骤如下：

1. 在pre-receive脚本中，提取本次推送的关键信息：推送人、目标分支、代码diff（用git diff <旧提交ID> <新提交ID>生成）。
2. 调用内部审批系统的API，提交审批请求，附带上述信息。
3. 脚本进入循环，定期轮询审批系统的状态（比如每30秒查一次）。
4. 若收到“批准”信号，脚本返回0（允许推送）；若收到“拒绝”或超时（比如1小时），返回非0（阻止推送）。

注意：这种方式存在严重弊端——推送进程长时间阻塞，用户体验极差；服务器资源被持续占用；容错性低（审批系统故障会导致所有推送停滞）。

更合理的协商依据（推荐用GitLab原生功能） #

与其强行用pre-receive钩子，不如说服团队采用GitLab原生的MR流程，理由如下：

• MR是GitLab专门为代码评审+审批设计的功能，完全覆盖你的需求：开发者先推送到功能分支，发起MR并指定审批人；审批人在GitLab界面直接查看代码diff、添加评论、完成审批；可以设置保护分支，禁止直接推送至目标分支，必须通过MR合并。
• 符合工具设计初衷：pre-receive钩子的定位是快速合规检查，MR才是团队协作中代码评审、审批的标准流程，使用原生功能更稳定、易维护。
• 体验与效率更优：开发者发起MR后无需等待审批完成，可以继续其他工作；审批人在GitLab内即可完成评审，不需要依赖外部系统。
• 可追溯性更强：MR的评审记录、审批操作都完整保存在GitLab中，便于后续审计和问题排查，自定义钩子的审批记录则分散难管理。

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