使用 GitHub Copilot 加速您公司的拉取请求

了解功能、启用开发人员并衡量Copilot的影响。

谁可以使用此功能？

GitHub Copilot业务 or GitHub Copilot Enterprise

在本文中

本指南的灵感来自 GitHub 的工程系统成功 playbook (ESSP)，其中推荐了推动工程系统改进的策略和指标。

如果你要启动 Copilot 的推出，我们建议定义目标、相应地规划推出，并向员工明确传达目标。 请参阅“使用 GitHub Copilot 实现公司工程目标”。

1.确定阻碍成功的因素

ESSP 建议的第一步是充分了解阻碍公司取得进步的障碍。 通过了解当前的基线、所需的未来状态以及阻碍进步的障碍，可确保更改具有针对性且有效。

在合并拉取请求时，团队通常会因审查周期冗长而遇到延迟。 这些延迟通常源于：

  • 难以理解的复杂代码更改
  • 使审查具有挑战性的不一致代码格式
  • 代码更改普遍缺乏上下文
  • 导致审查缓慢或难以解决的社会因素

审阅者还可能轻易忽视可能导致生产问题的细微错误。

这会导致开发流程出现瓶颈，拖慢整体交付速度并降低功能质量。

2.评估你的选项

下一步是评估并商定解决方案，以解决在第一步中确定的障碍。 在本指南中，我们将重点关注 GitHub Copilot 对已确定目标的影响。 新工具的成功推出还需要对文化和流程进行更改。

使用试点组运行新工具和流程的试用，以收集反馈并衡量成功。 有关在试验期间要使用的训练资源和指标，请参阅 3. 实施更改 和 需要监视的指标 部分。

          <a href="/proxy/https/github.com/enterprise/contact?ref_product=copilot&ref_type=engagement&ref_style=button" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline">
          <span>联系销售人员</span><svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-link-external" aria-label="link external icon" role="img"><path d="M3.75 2h3.5a.75.75 0 0 1 0 1.5h-3.5a.25.25 0 0 0-.25.25v8.5c0 .138.112.25.25.25h8.5a.25.25 0 0 0 .25-.25v-3.5a.75.75 0 0 1 1.5 0v3.5A1.75 1.75 0 0 1 12.25 14h-8.5A1.75 1.75 0 0 1 2 12.25v-8.5C2 2.784 2.784 2 3.75 2Zm6.854-1h4.146a.25.25 0 0 1 .25.25v4.146a.25.25 0 0 1-.427.177L13.03 4.03 9.28 7.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.75-3.75-1.543-1.543A.25.25 0 0 1 10.604 1Z"></path></svg></a>

Copilot 的帮助方式

          GitHub Copilot 提供了一套功能，旨在加速拉取请求评审过程、提高代码质量并提高协作，最终导致更快的合并时间。

通过利用 Copilot其功能，团队可以简化工作流、减少摩擦并确保一致的高质量代码。

生成完整且有用的拉取请求摘要

          Copilot 可以自动生成清晰简洁的 PR 摘要，从而节省开发人员的时间，并确保审阅者可以轻松理解 PR 的目的和更改。 这可减少误解的可能性，并加快审查流程。

在审查过程中协助审阅者

          GitHub Copilot 可用作功能强大的 PR 评论助手。

* Copilot 可以帮助解释复杂的代码更改，以便审阅者更快地了解 PR 的贡献。 * Copilot 可以直接在拉取请求评审界面 GitHub内提供存储库范围的上下文感知建议和潜在代码改进，帮助审阅者捕获潜在问题并更有效地提供建设性反馈。 * Copilot 可以帮助审阅者起草和编写清晰、一致且有效的审阅批注。

依据组织准则进行审查

  •         Copilot 可以在打开拉取请求之前查看 IDE 中的代码更改，或被分配为拉取请求的审阅者。
  • 使用规则集，你可以设置Copilot，根据自定义条件系统地审核拉取请求。
  • 使用自定义评审说明， Copilot 可以强制实施组织编码标准和最佳做法，自动标记潜在违规并建议修复。

这些功能可确保整个代码库的一致性，并帮助你在开发过程中尽早捕获错误，减少手动审查代码的需求，为开发人员和审阅者节省时间。

建议代码修复

基于拉取请求的审查评论，Copilot 可以帮助拉取请求作者快速实现所需代码更改以解决审查问题。

文化考量

除了推出 GitHub Copilot 外，还要解决可能阻碍你实现目标的任何社会或文化因素。

以下示例取自 ESSP 中的“反模式”部分。

  • 团队可能存在发布周期过长的问题，导致一次性部署大批量代码。**** 这可能是由担心频繁发布导致不稳定性、CI/CD 管道成熟度不足或严格的合规性要求所致。
  • 开发人员可能花太多时间来完善代码或添加不需要的功能。**** 这可能是完美主义文化或缺乏有效的优先级排序所致。
  • 开发人员可能为简单的问题构建过度复杂的解决方案。**** 这可能是由于不必要的追求“面向未来”，或是为通过复杂性来增加价值而承受的压力所致。

3. 实施更改

确定克服障碍的正确方法后，请实施并扩大你确定的解决方案。 若要成功推出新工具或流程，请将所有权分配给推出的每个部分，以透明方式传达目标，提供有效的培训，并衡量结果。

本部分为开发人员提供了示例场景、最佳做法和资源。 使用本部分来规划通信和培训课程，帮助员工以符合你的目标的方式使用 Copilot。

  •         [创建有用的拉取请求摘要](#create-helpful-pull-request-summaries)
  • 使用 Copilot 作为审阅助手
  •         [添加 Copilot 为审阅者](#add-copilot-as-a-reviewer)

  •         [在实施审查注释时获取帮助](#get-help-implementing-review-comments)

  •         [面向开发人员的最佳做法](#best-practices-for-developers)

  •         [资源](#resources)

创建有用的拉取请求摘要

  1. 创建拉取请求时，单击“添加说明”字段中的 Copilot 图标，然后单击“ 摘要”。
  2.           Copilot 将扫描拉取请求，并以文字形式提供更改概览，以及按文件影响列出的项目符号变更列表。
  3. 检查你对Copilot的描述感到满意。
  4. 当审阅者处理你的拉取请求时，他们将拥有进行审查所需的一切上下文。

用 Copilot 作为审阅助理

在作为审查者进入拉取请求时，可以使用 Copilot 来加快审查速度。

  1. 使用 Copilot 来理解拉取请求中的更改。

    • 请求 Copilot 对文件中的更改进行摘要，尤其适用于较长的 diff。 你可以通过点击文件右上角的 来从 diff 中选择特定文件。

      拉取请求的“files changed”选项卡的屏幕截图。“Ask Copilot about this diff”选项卡以红色突出显示。

    • 对于特定行中的更改，请将想要更好了解的行突出显示，并请求 Copilot 解释这些更改。 你可以先单击起始行号，按住 Shift 键，然后单击差异对比的结束行号来突出显示一组行。

      拉取请求的“files changed”选项卡的屏幕截图。所选的行会突出显示，下拉列表中出现“Explain”选项。

  2.           与 Copilot 一起**协作完成你的 PR 审查**。 在提示 Copilot 之前，不要忘记将具体文件 diff 附加到对话中。

    • 你可以通过以下方式询问 Copilot 对 PR 更改的看法：Provide your judgement as a PR Reviewer, both for functional and non-functional aspects that these changes bring。 请注意此提示如何要求 Copilot 考虑代码的功能和非功能性方面。

    • 对于自己的 PR 评论，请征求 Copilot 的第二意见：As my peer reviewer on this pull request, give me your feedback on my own review: YOUR-REVIEW-COMMENT. Do you think it's pertinent? Am I missing something?

  3. 与Copilot协作起草并完善您的审阅评论。

    • 在使用 Copilot 规划审查之后，可以要求其列出你应提供的评论：Make a list of review comments to add to the PR and tell me exactly in which file diff and lines each comment should be added。
    • 还可以要求 Copilot 创建您想要的评论的初稿，或者在发布之前优化评论：Help me draft review comments as discussed 或 Refine this review comment to make it clear, concise, and actionable。

添加 Copilot 为审阅者

为了缩短审阅时间并更快地合并拉取请求，请系统地使用 Copilot 代码评审：在打开拉取请求之前，先在 IDE 中进行代码审查，然后在 GitHub 中在 PR 上进行评审。

使用 Copilot 代码评审并不能取代人工代码评审的需要。 不过，执行上述步骤可帮助提高人工审查速度。

  •         **在** 打开拉取请求之前，开发人员应使用 Copilot 代码评审来请求查看其所有更改。

  •         **管理员** 应设置存储库或组织规则集，以在任何面向受保护分支的拉取请求上自动添加 Copilot 为审阅者。

  •         **团队主管** 应捕获团队的标准风格和规则，并将其设置为组织的自定义说明， Copilot 以便可以在评审中利用它们。
    • 请确保自定义说明包含至少一套提高代码可读性的样式建议，这将在拉取请求审查流程中提供帮助。
    • 为了减少因样式问题产生的 PR 审查评论，可以在仓库和组织级别的 Copilot 说明中设置相同建议。 这样，由其 Copilot 生成的代码将符合这些准则。

在实施审查注释时获取帮助

拉取请求作者可以通过 Copilot 的协助快速修复问题，从而加快 PR 审查评论的解决。

  • 对于 Copilot 自身给出的审查评论，要么直接提交建议修复，要么在提交前在 Copilot Workspace 中编辑。
  • 对于同行给出的审查评论，进入与 PR 审查评论相关的文件 diff，并将 diff 附加到 Copilot 对话助手 对话中。 然后，复制粘贴带有如下所示提示的审查注释：Suggest a fix for this review comment:
  • 如果您使用 VS Code，请在代理模式下让GitHub Copilot根据审阅注释执行所需的更改。

适用于开发人员的最佳做法

开发人员应该：****

  • 在推送前请求 Copilot 在你的 IDE 中进行审查，以尽早发现并解决问题。
  • 使用 Copilot 计划和完善自己的 PR 审查评论，以帮助 PR 作者了解和解决问题。
  • 在与 Copilot 的对话中附加相关 diff 上下文，包括具体代码行。

开发人员不应该：****

  • 无需测试即可应用 Copilot建议。
  • 完全依赖 Copilot 进行审查。
  • 忽视代码的可读性。

资源

  •         [AUTOTITLE](/copilot/using-github-copilot/using-github-copilot-for-pull-requests/creating-a-pull-request-summary-with-github-copilot)

  •         [AUTOTITLE](/copilot/using-github-copilot/code-review/using-copilot-code-review?tool=vscode#reviewing-changes)

  •         [AUTOTITLE](/copilot/how-tos/configure-custom-instructions/add-repository-instructions)

  •         [AUTOTITLE](/copilot/how-tos/agents/copilot-code-review/automatic-code-review)

  •         [AUTOTITLE](/copilot/customizing-copilot/adding-organization-custom-instructions-for-github-copilot)

要监视的指标

若要评估新工具的试用，并确保完整的推出提供一致的改进，请监视结果并在需要时进行调整。 我们建议考虑 质量、速度和开发人员幸福的关键区域，以及这些区域如何结合在一起，为业务成果做出贡献。

下面是一些指标，用于评估 Copilot 对此特定目标的影响。

  •         **开发人员满意度**：通过开发人员调查来衡量对工程工具的满意度。

  •           **每个开发者合并的拉取请求数**：可以使用 `pull request` webhook，确保 `action` 为 `closed` 且 `pull request` 对象内的 `merged` 属性为 `true`。

  •           **拉取请求交付周期**：衡量 PR 创建到合并之间的平均耗时。

  •           **拉取请求缺陷逃逸率**：衡量由于审查不充分导致的部署问题发生率。

  •           **拉取请求审查评论类型**：下载 PR 审查评论，使用基于 AI 的主题分类进行归类，并跟踪人类审查者在设计、可扩展性和策略方面的评论。