关于预接收挂钩
当发生推送时，每个脚本都在隔离的环境中运行，并且可以对推送的内容执行检查。 如果 exit status 为 0，脚本将导致接受推送，如果 exit status 不为零，则会拒绝接受推送。
使用预接收挂钩来满足业务规则、强制执行法规遵从性，并防止出现某些常见错误。
如何使用预接收挂钩的示例：
- 需要提交消息来遵循特定的模式或格式，例如包括有效的事件单号或超过一定长度。
- 通过拒绝所有推送来锁定分支或仓库。
- 通过阻止关键词、模式或文件类型来防止将敏感数据添加到仓库。
- 防止 PR 作者合并他们自己的更改。
可以在 github/platform-samples 存储库中查看 GitHub Enterprise Server 的预接收挂钩示例。
对性能和工作流程的影响
对开发者及其工作流程的影响可能很大，因此必须谨慎考虑。 基于业务需求并经过深思熟虑实施的预接收挂钩将为整个组织带来最大好处。
预接收挂钩可能会对 你的 GitHub Enterprise Server 实例 的性能产生意外影响，因此应谨慎实施和审查。
由于实例的所有用户都存在出现故障和性能影响的风险，因此建议执行以下操作。
- 避免在预接收挂钩中发出 API 请求。 尤其是，我们强烈建议不要向外部服务发出请求，这可能需要更长的时间，并且可能会造成性能影响。
- 避免在预接收挂钩中长时间运行 Git 操作。 如果预接收挂钩在大型或繁忙存储库中执行 Git 操作，则可能会对实例的 Git 和整体性能产生负面影响。
注意
为了避免因超时而拒绝推送，所有合并预接收挂钩的运行时间都应在 5 秒内。
预接收挂钩超时
GitHub Enterprise Server 中的预接收挂钩具有 5 秒的固定超时预算（在所有挂钩之间共享）。 这是一个有意的设计，以防止长时间运行的挂钩导致资源耗尽，并防止失控脚本无限期地阻止存储库操作。
存储库的所有预接收挂钩共享 累积超时预算：
- 如果挂钩 A 需要 3 秒，则挂钩 B 将剩余 2 秒（默认值为 5 秒）
- 如果挂钩 A 在 5 秒时超时，则挂钩 B 永远不会执行
重要
预接收挂钩超时的处理方式与退出代码不同：
-
**退出代码**：强制配置得到遵守（非强制挂钩不会阻止推送）
**超时**：无论强制配置如何，推送都可能失败
超时行为
| Scenario | 强制 = 已启用 | 强制 = 已禁用/测试中 |
|---|---|---|
| 退出代码 ≠ 0 | 推送被拒绝 | 推送继续（仅警告） |
| 超过超时 | 推送被拒绝 | 警告 + 推送仍可能失败 |
在推送规则和预接收挂钩之间进行选择
可以使用推送规则和预接收挂钩来控制用户可以推送到仓库的更改。 这两者都有助于强制实施策略，但它们的工作方式不同，并且专为不同的用例而设计。
推送规则是跨仓库强制实施常见策略的内置方法。 可以使用它们阻止不符合特定条件的推送，例如对特定文件和路径、文件大小或文件类型的更新。 可以通过 UI 或 API 管理推送规则。 由于推送规则属于仓库规则集的一种类型，因此它们支持审核日志，并可与评估模式配合使用，以预览更改或在需要时进行绕过。
如果你希望轻松实现以下操作，请使用推送规则：
- 在不编写脚本的情况下强制实施标准策略。
- 在组织和仓库中一致地应用策略。
- 通过 GitHub 的 UI 和 API 管理规则。
- 使用 GitHub 本机功能，例如审核日志记录、绕过列表和规则见解。