关于 Webhooks
Webhooks 让您能够订阅软件系统中的事件，并在这些事件发生时自动将数据交付到您的服务器。
Webhooks 用于实时接收数据，而不是轮询 API（间歇性调用 API）来检查是否有可用数据。使用 Webhooks 时，您只需在创建 Webhook 时表达一次对事件的兴趣。
Webhooks 可用于广泛的场景，包括
- 在外部 CI 服务器上触发 CI（持续集成）流水线。例如，当代码推送到分支时触发 Jenkins 或 CircleCI 的构建。
- 将 GitHub 上的事件通知发送到协作平台。例如，在拉取请求收到审查时向 Discord 或 Slack 发送通知。
- 更新外部问题跟踪系统，如 Jira。
- 部署到生产服务器。
- 实时记录 GitHub 上的事件，以用于审计。
GitHub 上的 Webhooks 概述
创建 Webhook 时，您需要指定一个 URL 并订阅在 GitHub 上发生的事件。当您订阅的事件发生时，GitHub 会向您指定的 URL 发送包含该事件数据的 HTTP 请求。如果您的服务器已在该 URL 上监听 Webhook 推送，它就可以在收到请求后执行相应操作。
例如，您可以订阅代码推送到仓库、拉取请求被打开、GitHub Pages 站点被构建或团队新增成员等事件。服务器收到推送后，可以执行代码部署到生产环境、触发 CI 流水线、发送通知，或为新成员创建 GitHub 项目等操作。
您必须在特定的仓库、组织、GitHub Marketplace 账户、GitHub Sponsors 账户或 GitHub App 中创建 Webhook。该 Webhook 只能访问其所在的仓库、组织、Marketplace 账户、Sponsors 账户或 App 中可用的资源。更多信息请参阅 Webhooks 类型。
有关创建 Webhook 的详细说明，请参阅 创建 Webhook。有关可订阅的事件类型，请查看 Webhook 事件与负载。如需了解如何配置服务器以响应负载交付，请参阅 处理 Webhook 推送。
注意
GitHub Webhooks 目前不支持 IPv6，但未来会支持。/meta REST API 端点返回 IPv6 地址段，以便实现该过渡。
在 Webhooks 与 REST API 之间的选择
使用 Webhook 相较于使用 API 具有以下优势
- Webhooks 所需的工作量和资源比轮询 API 更少。
- Webhooks 的可扩展性优于 API 调用。如果需要监控大量资源，对每个资源都调用 API 可能会很快耗尽 API 速率限制配额。相反，您可以订阅多个 Webhook 事件，仅在事件发生时收到信息。
- Webhooks 能实现近实时更新，因为它们在事件发生时立即触发。
如果您只需偶尔获取信息，或只想从少量资源获取信息且没有扩展计划，可在需要时调用 API。
有关使用 Webhook 时的最佳实践，请参阅 使用 Webhook 的最佳实践。
注意
GitHub Services（有时称为 Service Hooks）已被废弃，推荐使用 Webhook 集成。有关将集成从 GitHub Services 迁移到 Webhook 的更多信息，请阅读 博客文章。