GitHub可通过Coroid进行连接GitHub应用或个人访问令牌。可在此处进行配置设置 → 连接 → 源代码管理。
应用或令牌
优先选择应用。它能按代码库而非用户授予访问权限，即便设置该应用的用户离职，它仍能正常运行，且无需轮询即可接收Webhook事件。
如果应用安装需要无法获取的组织管理员审批，则可使用令牌。
| GitHub应用 | 个人访问令牌 | |
|---|---|---|
| 访问范围 | 按代码库划分 | 用户可查看的所有内容 |
| 即使安装者离职仍可持续运行 | 是 | 否 |
| Webhook事件 | 是 | 轮询 |
| 归属关系 | 该应用 | 令牌所有者 |
安装应用
在GitHub中选择GitHub，然后按照安装流程操作。设置 → 连接 → 源代码管理系统会询问您要授予哪些代码库的访问权限；后续也可从GitHub自身设置中修改该配置。
如果在创建项目时未显示某个代码库，几乎可以肯定是该应用未被授予对该代码库的访问权限——这是最常见的原因。
使用令牌
创建一个具备相应范围的经典令牌，或创建一个具备内容及拉取请求读写权限的细粒度令牌，然后将其粘贴到源代码控制设置中。repo范围，或具有内容和拉取请求读取
与写入权限的细粒度令牌，然后将其粘贴到源代码管理设置中。
令牌在静态存储时会加密，API绝不会返回令牌内容，也不会将其包含在设置导出文件中。
GitHub议题
同一连接也支持将议题导入为工作任务。详见导入工作任务。
转化为工作任务的事件
使用应用时，事件自动化功能可发送一个pull request、新议题或提及Coroid的评论至Qualification模块。详见触发器与目标。
只有当事件的创建者对代码库拥有写入、维护或管理员权限时，这些事件生成的合格工作任务才会自动启动。Coroid会针对每个事件向GitHub发起请求。对于pull request而言，创建者为发起该议题的人员，而非标注或合并该议题的人。其他人的工作任务会被创建出来并等待有人启动。只有当提及Coroid的评论的创建者拥有写入权限时，该评论才会被纳入考量。
审核拉取请求
使用应用时，Coroid会检查并审核人员及其他工具创建的拉取请求，而不仅仅是Coroid自身创建的请求。Coroid Quality Control会执行项目的检查并将结果标记为Coroid Quality Control检查项。Coroid Review会针对有疑问的代码行添加评论并形成审核意见，同时会生成一个名为Coroid Review的检查项。这两项设置均在Quality Control下的拉取请求模块中完成。详见拉取请求。
Coroid在您的代码库中的操作
- 读取代码以理解并进行修改
- 为每个任务创建独立分支
- 推送该分支并针对您的基准分支创建pull request
它绝不会直接提交到您的默认分支或自行合并。只有当人员在GitHub中合并pull request，或点击批准并合并在Coroid中。
设置为仅本地模式的项目仅执行上述第一步操作，其余步骤均不执行：Coroid会读取并拉取代码，分支、审核及检查结果均保存在Coroid内部。即便应用或令牌允许，它也不会推送代码、创建或评论拉取请求，也不会发布检查运行结果。详见同步模式或仅本地模式。
您的分支保护规则、必填检查项及审核规则将保持不变。批准并合并也会通过pull request执行合并操作，因此同样的规则会决定合并是否成功。详见合并。