关于 网络钩子
Webhook 允许订阅软件系统中发生的事件，并在发生这些事件时自动接收传送到服务器的数据。
Webhook 用于在发生时接收数据，而不是通过轮询 API（间歇性调用 API）确认数据是否可用。 借助 Webhook，只需在创建 Webhook 时表达一次对事件的兴趣。
Webhook 用于各种应用场景，包括：
- 在外部 CI 服务器上触发 CI（持续集成）管道。 例如，当代码被推送到分支时，在 Jenkins 或 CircleCI 中触发 CI。
- 将 GitHub 上发生的事件通知发送到协作平台。 例如，当对拉取请求进行审阅时，向 Discord 或 Slack 发送通知。
- 更新外部问题跟踪器，例如 Jira。
- 部署到生产服务器。
- 出于审计目的，在 GitHub 上实时记录事件日志。
关于 Webhook GitHub
创建 Webhook 时，您需要指定一个 URL，并订阅在 GitHub 上发生的事件。 当您的 Webhook 所订阅的事件发生时，GitHub 会向您指定的 URL 发送一个 HTTP 请求，其中包含该事件的相关数据。 如果服务器设置为侦听该 URL 处的 Webhook 交付，则可在收到 Webhook 交付时采取措施。
例如，你可以让 Webhook 订阅在代码被推送到存储库、拉取请求被打开、构建 GitHub Pages 站点或向团队添加新成员时发生的事件。 服务器可以通过将代码部署到生产环境、触发 CI 管道、发送通知或为新团队成员创建 GitHub 项目来做出响应。
您必须在特定仓库、组织、GitHub Enterprise、 或 GitHub App 中创建 webhook。 Webhook 只能访问其安装所在的存储库、组织、GitHub Enterprise、或GitHub App中可用的资源。 有关详细信息，请参阅“Webhook 的类型”。
有关创建 Webhook 的详细信息，请参阅“创建网络钩子”。 有关可订阅的事件类型的详细信息，请参阅“Webhook 事件和有效负载”。 有关通过配置服务器执行操作来响应有效负载交付的详细信息，请参阅“处理 Webhook 交付”。
注意
GitHub Webhook 目前不支持 IPv6，但将来会支持 IPv6。 /meta REST API 终结点返回 IPv6 范围以启用该转换。
选择 Webhook 或 REST API
与使用 API 相比，使用 Webhook 具有以下优势：
- 与轮询 API 相比，Webhook 所需的工作量和资源更少。
- Webhook 的缩放性能优于 API 调用。 如果需要监视许多资源，为每个资源调用 API 可能会导致快速达到 API 速率限制配额。 我们可以转而订阅多个 Webhook 事件，并仅在事件发生时接收信息。
- Webhook 可允许几乎实时的更新，因为 Webhook 会在事件发生时被自动触发。
如果只需要一次或间歇性的信息，或者只想从少量资源获取信息，且没有纵向扩展计划，则可以在需要相关信息时调用 API。
有关使用 Webhook 时要遵循的最佳做法的信息，请参阅“使用 Webhook 的最佳做法”。
注意
GitHub服务（有时称为服务挂钩）有利于退休与 Webhook 集成。 有关将集成从使用 GitHub Services 迁移到 webhook 的详细信息，请参阅 blog post。