Skip to main content

​
为什么要将 Devin 与 GitHub 集成？

将 Devin 与你的 GitHub 组织集成后，Devin 就可以创建 Pull Request (PR) 、回复 PR 评论，并直接在你的代码仓库中协作。这样，Devin 就能作为你工程团队中的正式贡献者参与工作。 要开始使用，请打开 Settings → Connections → GitHub，点击 Add Connection，并按照提示进行操作。你需要选择 Devin 可以访问的代码仓库，并审核所需的权限。
在使用 GitHub Enterprise Server，或启用了数据驻留的 GitHub Enterprise Cloud？ 请参阅 GitHub Enterprise Server Integration guide，了解配置说明。

​
设置集成

要创建和管理 Devin 集成，您必须是 GitHub 组织的管理员。遇到问题？请查看我们的常见问题。
  1. 在您的 Devin 账户中，打开 Settings → Connections → GitHub，然后点击 Add Connection。
Devin
  1. 如果您尚未登录 GitHub，系统会提示您进行身份验证。
Devin
  1. 选择您希望连接到 Devin 的 GitHub 组织。
Devin
  1. 选择是否授予 Devin 对 All repositories 或 Select repositories 的访问权限，以控制 Devin 可访问的代码仓库范围。
Devin
  1. 完成 GitHub 授权后，系统会将您重定向回 Devin 的设置页面，您可以在该页面确认集成已激活。
Devin
我们建议在主分支上启用分支保护规则，以确保在 Devin 合并更改之前，所有必需的检查都已通过。

​
使用 Devin 的 GitHub 集成

​
针对 Core 和 Teams 用户

完成集成配置后，你可以在 Devin Web 应用中的提示中直接使用 @ 提及代码仓库。

​
适用于 Enterprise 用户

完成集成配置后，你可以在 Settings > Repositories 中，将代码仓库分配给特定组织。
Devin
如果你是首次使用某个代码仓库，我们建议先完成在引导流程中设置开发环境，以确保 Devin 获取到关于你的代码库的准确且最新的信息。 只要会话尚未被归档，Devin 就会自动回复其会话正在处理的 PR 上的评论。若要从任意 PR 启动新会话，请参阅从 PR 评论启动 Devin。

​
通过 PR 评论启动 Devin

你无需离开 GitHub 即可把工作交给 Devin。在已连接 Devin 的仓库中，于任意处于开启状态的 pull request 下发表一条以 /devin 开头的评论，并在后面写明你希望完成的事情：
Devin 会针对该仓库启动一个新会话，将该 PR 作为上下文 (必要时接管该 PR) ，并在 PR 中回复会话链接。 要求：
  • 位于评论开头 —— 命令必须写在评论的最开头。命令不区分大小写，在 PR 对话评论和行内 review comments 中均可使用。
  • 仅限打开的 PR —— 对 issue 以及已关闭或已合并 PR 的评论会被忽略。
  • 写入权限 —— 评论者需拥有该仓库的 write 或 admin 权限。
  • 已关联账户 —— 评论者的 GitHub 账户必须已关联到其 Devin 账户，并且必须是某个 Devin 组织的 member，该组织需拥有该仓库的访问权限以及使用 Devin 会话的权限。
如果已有 Devin 会话正在处理该 PR，/devin 评论会被发送到该会话，而不会启动新会话。

​
用户关联

上述 GitHub App 连接是组织级的。在此基础上,每个用户还可以将自己的账户关联到 Devin,让 Devin 能以其身份进行操作:Devin 在其会话中提交的拉取请求会以该用户为作者,用户通过 Devin Review 提交的评论或 review 也会显示在其账户名下。 关联个人账户的步骤:
  1. 在个人账户设置中前往 Settings > Connections
  2. 在账户列表中找到 GitHub 一行
  3. 点击 Link 并完成 GitHub 授权
若之后需要解除关联,请在同一行点击 Unlink user。解除关联时,Devin 会向 GitHub 撤销该 OAuth token。
只有当你的组织已建立 GitHub 连接时,GitHub 这一行才会出现。 如果没有看到,请确认你是某个已设置 GitHub 集成 的 Devin 组织的成员。GitHub Enterprise Server 实例会显示为单独的 GitHub Enterprise 行并标注主机名,关联方式相同。
若要让 Devin 以关联用户的身份提交拉取请求,admin 还需在 Settings > Devin > 拉取请求 中设置 Open PRs as:
  • Devin:始终以 Devin 的身份提交拉取请求
  • User:用户已关联 git 账户时以该用户身份提交,否则以 Devin 身份提交
  • User only:以该用户身份提交;若其 git 账户未关联则失败(automation 和服务用户仍会回退为 Devin)
同一 拉取请求 部分中还有两个相关设置:
  • Allow PRs to be opened by session participants:允许 Devin 以任意会话参与者的身份提交 PR,而不仅限于会话发起人。
  • Require session access for PR comments:仅当评论者有权访问对应的 Devin 会话时,才将 PR 评论转发到该会话。企业管理员可在所有组织中强制执行此设置。

​
在 GitHub 中管理 Devin 的权限

在设置过程中，你可以授予 Devin 访问你组织中所有代码仓库的权限，或将其访问范围限制为特定代码仓库。 你可以随时通过 GitHub 的设置调整代码仓库访问权限：
  1. 前往你的 GitHub 组织的 Settings > GitHub Apps (例如：https://github.com/organizations/<org_name>/settings/installations)
  2. 找到 Devin.ai 集成并选择 Configure
  3. 在 Repository access 中，选择授予对所有代码仓库的访问权限，或仅选择特定代码仓库
  4. 点击 Save 以应用更改
Devin
Devin 需要以下权限： 对以下项目的**读取 (Read) **访问权限： 对以下项目的**读取 (Read) 和写入 (Write) **访问权限： 这些权限使 Devin 能够像普通贡献者一样在你的代码仓库中工作——推送分支、打开拉取请求，并参与 PR 讨论。
当 Devin 的 GitHub App 申请新权限时，GitHub 会发邮件通知你的组织管理员，请其在安装设置中批准。在获批之前，Devin 会继续使用已授予的权限工作。

​
Pull Request 模板

当 Devin 创建 Pull Request 时，它会使用你仓库中的模板来组织 PR 描述。如果你提供了模板，Devin 在向 GitHub 提交 PR 时会遵循该模板的格式。 你可以在下方任一受支持的 PULL_REQUEST_TEMPLATE 位置添加一个名为 devin_pr_template.md 的文件，为 Devin 提供单独的模板，而无需修改你面向人工审核的默认模板。如果你希望 Devin 包含额外的上下文信息 (例如审阅者检查清单或已修改文件的 Mermaid 图表) ，这会特别有用。

​
模板查找顺序

Devin 会按以下顺序查找模板，并使用第一个匹配项：
  1. PULL_REQUEST_TEMPLATE/devin_pr_template.md
  2. docs/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  3. .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  4. pull_request_template.md
  5. docs/pull_request_template.md
  6. .github/pull_request_template.md
如果未找到任何模板，Devin 会使用其默认的 PR 描述格式。
如果你希望 Devin 使用你现有的 pull_request_template.md，请将其复制或创建符号链接到上述任一 devin_pr_template.md 路径。
有关 GitHub pull request 模板的更多信息 (支持的位置、多模板、查询参数等) ，请参阅 GitHub 文档 (GitHub Docs) ：为你的仓库创建 pull request 模板。

​
提交签名

要使用 GPG 为 Devin 的提交签名，请在你的环境中配置该密钥，以便它能在不同会话间持续保留。在会话终端中生成密钥是行不通的——每个 Devin 会话都会从 machine image 的 fresh copy 启动，因此在会话过程中创建的任何密钥都会在会话结束时被丢弃。
通过环境配置进行 GPG 签名，只有在 Devin 是提交者时才会生成 Verified 提交。GitHub 会根据提交者邮箱验证签名；但在任何提交作者模式下，只要提交者是发起 请求的用户 (“Co-authored (you + Devin)”、“You only”、“Devin as author, you as committer”) ，Devin 就会使用各用户自己的邮箱作为提交者进行提交—— 这就无法与单个共享 GPG 密钥匹配。在依赖此设置之前，请让 enterprise admin 在 Enterprise Settings > Devin > Git commit attribution 下将提交作者模式设置为 “Devin only”、“Co-authored (Devin + you)” 或 “You as author, Devin as committer”。该 enterprise-wide 设置会覆盖每位用户的个人 Git commit author 偏好；当它保持为 Per-user (Default) 时，则以各用户在 Settings > Preferences 下的自身选择为准。如果你的组织不属于某个企业，则没有 org-wide 控制项：每位启动 Devin 会话的用户都必须在 Settings > Preferences 下将其个人 Git commit author 设置为上述模式之一。
请在 org-wide 层 (如果你的所有 orgs 都需要，则在 enterprise 层) 进行此设置，以便每个代码仓库都能获得已签名提交配置：
  1. 创建 (或选择) 一个专用的 GitHub 用户账户，由它同时拥有提交作者身份 以及 Devin 用来推送的凭据——例如 devin@company.com。同一个账户同时承担这两项职责会让签名设置更简单；如果使用两个账户，则需要将下文所述配置拆分到两边。
  2. 在本地使用该账户的邮箱作为 UID 生成一个 GPG 密钥，并按照 GitHub 的指示操作。
  3. 将公钥上传到与 GPG UID 匹配的已验证邮箱所属的 GitHub 账户中，位置为 GitHub Settings > SSH and GPG keys。GitHub 会根据 提交者 身份验证签名，而不是根据推送身份——公钥必须存在于拥有 user.email 中该邮箱的账户上。 (如果这正是你用于推送的同一个专用账户，那么这一步只需执行一次。)
  4. 导出私钥，将其进行 base64 编码，并将它 (以及对应的 GIT_USER_NAME / GIT_USER_EMAIL) 作为 secrets 添加到 Settings → Resources → Secrets。
  5. 在你的org-wide 环境配置中导入该密钥，并在每次会话启动时启用签名。完整 YAML 请参见可直接复制粘贴的 GPG commit signing example。
提交者邮箱 (user.email) 必须与 GPG 密钥上的某个 UID 匹配，同时该邮箱还必须是你上传公钥所在 GitHub 账户上的已验证邮箱。如果这三者中有任何一个不匹配，GitHub 都会将该提交显示为 Unverified，即使签名本身是有效的。

​
安全注意事项

  • 分支保护： 我们建议在主分支上启用分支保护规则，以确保在 Devin 合并更改之前，所有必需的检查都已通过。
  • 组织级权限： Devin 使用授予组织级别的权限，而不是运行会话的个人用户的权限。
  • 一致的访问控制： 所有同时加入 GitHub 组织和 Devin 组织的用户，共享相同的 Devin 集成权限。
  • 仓库创建： Devin 无法在你的 GitHub 账户中创建新的仓库。

​
IP 白名单

如果你的组织在访问 GitHub 时需要配置 IP 白名单，请将以下 IP 地址加入允许列表：
  • 100.20.50.251
  • 44.238.19.62
  • 52.10.84.81
  • 52.183.72.253
  • 20.172.46.235
  • 52.159.232.99
  • 4.204.199.103
  • 140.232.64.0/26
这些 IP 地址可能会在未来更新中发生变化。我们建议你关注我们的发行说明，以便了解任何变更。

​
故障排查：GitHub organization 连接到了错误的 Devin organization

如果你的 GitHub organization 已经连接到一个你无权访问的 Devin organization，GitHub org admin 可以移除现有安装，并将其重新安装到另一个 Devin organization 下。
我们建议在移除安装前，先与当前 Devin organization 的所有者确认。
  1. 前往 github.com/settings/installations，然后点击 Devin.ai Integration 旁边的 Configure。 如有需要，可使用右上角的 Go to settings page 下拉菜单切换到正确的 GitHub organization context。
    切换 GitHub 设置 context
  2. 在安装页面中，滚动到 Danger zone 部分并点击 Uninstall，从 GitHub organization 中移除 Devin.ai Integration。
    卸载 Devin.ai Integration
  3. 返回 app.devin.ai 并刷新页面。现在，你可以在你的 Devin organization 下重新安装 GitHub integration。

​
GitHub 集成常见问题

可以。用户可以将 GitHub 组织账号或个人 GitHub 账号连接到其 Devin 组织。不过，我们建议连接具备 Devin 访问团队所需代码仓库的相应权限的账号。
只有安装了该 GitHub 集成的组织成员，才能在其 Devin 会话中使用该集成。Devin 会根据用户的组织成员身份继承对该 GitHub 集成的访问权限。
加密密钥由 AWS KMS 管理，并会定期轮换。