关于 web 挂钩
Webhook 允许订阅软件系统中发生的事件，并在发生这些事件时自动接收传送到服务器的数据。
Webhook 用于在发生时接收数据，而不是通过轮询 API（间歇性调用 API）确认数据是否可用。 借助 Webhook，只需在创建 Webhook 时表达一次对事件的兴趣，即可实现前述目的。
Webhook 用于各种应用场景，包括：
- 在外部 CI 服务器上触发 CI（持续集成）管道。 例如，当代码被推送到分支时，在 Jenkins 或 CircleCI 中触发 CI。
- 当 GitHub 上发生事件时，向协作平台发送通知。 例如，当对拉取请求进行审阅时，向 Discord 或 Slack 发送通知。
- 更新外部问题跟踪器，例如 Jira。
- 部署到生产服务器。
- 记录 GitHub 上发生的事件用于审核。
关于 GitHub
Webhook
创建 Webhook 时，请指定 URL 并订阅 GitHub 上发生的事件。 发生 Webhook 订阅的事件时，GitHub 会将包含有关该事件数据的 HTTP 请求发送到指定 URL。 如果服务器设置为侦听该 URL 处的 Webhook 交付，则可在收到 Webhook 交付时采取措施。
例如，可以为 Webhook 订阅向存储库推送代码、打开拉取请求、生成 GitHub Pages 站点或新成员加入团队时发生的事件。 服务器可以通过将代码部署到生产环境、触发 CI 管道、发送通知或为新团队成员创建 GitHub 项目做出响应。
必须在特定存储库，组织，GitHub Enterprise， 或 GitHub App 中创建 Webhook。 Webhook 仅可访问安装了 Webhook 的存储库，组织，GitHub Enterprise， 或 GitHub App 中的可用资源。 有关详细信息，请参阅“Webhook 的类型”。
有关创建 Webhook 的详细信息，请参阅“创建 web 挂钩”。 有关可订阅的事件类型的详细信息，请参阅“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 服务（有时称为服务挂钩）于 2019 年弃用，以支持与 Webhook 集成。 有关将集成从使用 GitHub 服务迁移到使用 Webhook 的详细信息，请参阅 博客文章。