关于 Apps
App 是一种集成类型，你可以构建它来与 交互并扩展其功能。 可以构建 App 来提供灵活性并减少流程中的冲突，而无需登录用户或创建服务帐户。
Apps 的常见用例包括：
- 自动执行任务或后台进程
- 支持“使用 登录”，从而让用户能够使用其 帐户登录，以便在生态系统中提供其标识
- 用作开发人员工具，允许用户登录到 App 来使用 ，然后应用可以代表用户进行操作
- 将工具或外部服务与 集成
与 OAuth apps 一样， Apps 使用 OAuth 2.0，可以代表用户执行操作。 与 OAuth apps 不同的是， Apps 也可以独立于用户进行操作。
Apps 可以直接安装在组织和个人帐户上，并获得对特定仓库的访问权限。 它们拥有内置 web 挂钩和狭窄的特定权限。
默认情况下，只有组织所有者才可管理组织中 的设置。 若要允许其他用户更改组织拥有的 应用的开发人员设置，所有者可以向他们授予 应用管理器权限。 应用管理器无法管理第三方应用程序。 有关在组织中添加和删除 应用管理器的详细信息，请参阅“组织中的角色”。
生成 App
若要生成 App，首先需要注册 App。 有关详细信息，请参阅“注册 应用”。
然后，需要编写代码以向 App 添加功能。 可以使用 App 注册中的凭据向 的 API 发出经过身份验证的请求。 若要详细了解如何为 App 编写代码，请参阅“关于为 应用编写代码”。 若要详细了解如何发出经过身份验证的请求，请参阅“关于使用 应用进行身份验证”。
为 App 编写代码后，需要在某个位置运行应用。 如果你的应用是网站或 Web 应用，则可以将应用托管在服务器（如 Azure 应用服务）上。 如果你的应用是客户端应用，它可能会在用户的设备上运行。
要使用 App，需要在组织或个人帐户上安装此应用。
- 如果将 App 设为私有，则只能在拥有该应用的帐户上进行安装。
- 如果 App 属于公有，则其他用户和组织也可以安装此应用。
了解要生成的 App 类型
设计 App 有多种方法可供你选择，具体取决你希望应用包含的功能。
代表用户执行操作的 Apps
如果希望应用代表用户执行操作，则应使用用户访问令牌进行身份验证。 这种类型的请求有时称为“用户到服务器”，这意味着应用将受到已授予应用的权限以及用户权限的限制。 使用此模式时，用户必须先授权应用，然后应用才能执行操作。 有关详细信息，请参阅“代表用户使用 应用进行身份验证”。
可以使用 App 创建的一些自动化示例包括，其中应用代表用户执行操作：
- 使用 作为生态系统标识提供者的 App。
- 在 顶部添加可能对 用户有用的服务的 App。 可以通过 Marketplace 或公开应用与其他开发人员共享应用。
以应用自身身份执行操作的 Apps
如果希望应用以应用自身身份而不是用户身份执行操作，则应使用安装访问令牌进行身份验证。 这种类型的请求有时称为“服务器到服务器”，这意味着应用将受到已授予应用的权限的限制。 有关详细信息，请参阅“验证为 应用程序安装”。
可以使用 App 创建的一些自动化示例包括，其中应用以自身身份执行操作：
- 使用 Webhook 响应给定一组特定条件的事件的 App。 例如，可以围绕 REST API 终结点创建自动化来审批 fine-grained personal access token 的请求，在给定特定策略的情况下批准请求。
- 帮助存储库参与者的 App。 例如，应用可以在参与者创建拉取请求或发表评论后发布有用的资源。
- 生成生存期较短的令牌以提供给其他 CI/CD 工具或从存储库中提取信息的 App。
响应 Webhook 的 Apps
如果希望应用响应 上的事件，则应用应订阅 Webhook。 例如，你可能希望应用在拉取请求打开时发表评论。 有关详细信息，请参阅“将 Webhook 与 应用配合使用”。
可以执行某些操作的 Apps
设置 App时，可以选择该应用的特定权限。 这些权限确定应用可以通过 API 执行哪些操作、应用可以代表登录用户执行哪些操作，以及应用可以接收哪些 Webhook。 有关详细信息，请参阅“为 Apps 选择权限”。