教程：审核合并请求

极狐GitLab 合并请求审查有助于确保只有高质量的代码进入您的代码库。本教程向您展示如何在极狐GitLab 中审查合并请求。它将引导您了解合并请求本身的结构，然后是提供建设性、有帮助的反馈的过程。到本教程结束时，您可以批准合并请求，或请求更多更改。

要审查合并请求：

1. 前往合并请求
2. 了解合并请求的结构
3. 获取高层次视图
   1. 检查相关议题
   2. 检查侧边栏
   3. 检查评论
4. 阅读代码变更
   1. 浏览变更获取概览
   2. 深入检查每个文件
   3. 测试代码
   4. 检查流水线
   5. 重新审查考虑事项
   6. 考虑整体情况
5. 完成您的审查
   1. 撰写您的审查评论
   2. 总结您的审查
6. 执行清理任务

前往合并请求#

1. 在左侧边栏中，选择 搜索或转到 并找到您的项目。
2. 可以：
   • 按 Shift + r 前往您的 审核请求 页面。
   • 在左侧边栏中，选择 合并请求 (
     ) > 审核请求。

了解合并请求的结构#

合并请求有一个包含四个选项的二级菜单。您在审查过程中会在不同时间使用这些区域：

• 概览: 合并请求的描述、其当前可合并性的报告、带有评论的 Activity 区域和提供更多信息的侧边栏。
• 提交: 此合并请求中的提交列表，最新的提交在前。
• 流水线: 针对该合并请求内容运行的 CI/CD 流水线列表。
• 变更: 此合并请求中提议的变更的差异，显示删除、添加和更改的行。

概览 选项卡中的侧边栏包含有关合并请求本身的重要元数据：受让人、审查员、标签、里程碑和时间跟踪。

获取合并请求的高层次视图#

在开始审查代码之前，您应该从高层次评估合并请求。了解合并请求的上下文和目的：它试图做什么，为什么。将这些需求与您的技能进行比较，同时问自己以下问题：

1. 合并请求背后的故事是什么？我在这个领域有足够的背景来进行深思熟虑的审查吗？
2. 要求什么类型和深度的审查？例如，范围狭窄的错误修复和深度架构审查可能有非常不同的审查期望。
3. 您是审查这项工作的合适人选吗？它需要的审查类型是否与您的技能和能力匹配？

首先查看合并请求的描述。它应该是议题中的问题解决方案或功能请求。

• 作者是谁？ 您对这个人的工作熟悉吗？如果您熟悉这个人，他们通常在哪部分代码库工作？稍后，您对作者的了解可以帮助您评估他们的更改。
• 目标是什么？ 阅读描述以了解作者的意图。
• 是草稿吗？ 草稿通常是不完整的或理论上的解决方案。草稿合并请求可能需要与完全完成的合并请求不同的审查水平。
• 您如何重现问题？ 描述是否说明了如何重现问题、测试更改或尝试新功能？它是否包含指导您操作的屏幕截图？

在描述的下方，检查合并请求小部件以了解这项工作的当前状态。此示例显示了缺少批准、仍处于草稿模式并且有未解决讨论线程的合并请求的小部件：

• 它是否交叉链接到议题？ 检查描述和合并小部件中是否有指向其他议题的链接。有些合并请求很简单，但有些需要您阅读相应的议题以了解此合并请求是如何产生的。更复杂的合并请求应指向包含完整信息的议题。
• 流水线状态是什么？ 流水线是绿色的吗？红色流水线表示存在问题。如果您看到未完成或被取消的流水线，您无法评估工作的完整可合并性。

检查相关议题#

如果存在相关议题，并且合并请求感觉复杂到您需要更多信息，请浏览议题描述。

• 问题和解决方案是否分开？ 议题应描述并调查问题，合并请求应专注于解决方案。
• 合并请求作者是否参与了议题？ 在整个审查过程中，考虑谁帮助定义了问题（或功能）。理想情况下，这些人也参与了合并请求。

检查侧边栏#

• 它有哪些标签？ 标签可以为合并请求的内容提供线索。根据您团队的工作流程，不完整或缺失的标签可能是无害的，也可能表明此合并请求缺乏完整信息。

  • 如果标签与您的专业领域匹配，您可能是审查此合并请求的合适人选。
  • 如果标签匹配您没有的专业领域，您可能需要将合并请求重新分配给其他审查员。
  • 添加您的工作流程期望的任何标签。

  在此示例中，即使确切的标签对您来说不熟悉，您也可以确定此合并请求是关于数据库错误的：

  

• 谁是审查员？ 扫描审查员列表中的姓名。它们是否与您期望的工作类型匹配，基于描述和（可选）标签？考虑谁在场，谁不在场。这些名字告诉您这个合并请求在其审查周期中的哪个阶段？您是否需要添加或移除任何人？

• 是否有审查员已批准？ 如果您了解这些审查员及其专业领域，您可以大致了解哪些方面的建议更改需要您的关注。

  在此示例中，Thomas 和 Nick 都是审查员。Thomas 尚未审查 (

  ) 合并请求。Nick 已审查并批准 (
  ):

  

检查评论#

在 Overview 页面上，阅读作者和其他人留下的评论。在阅读代码变更时牢记这些讨论。

您是否在评论中看到了之前审查的证据？大量评论可能会影响您对这项工作的审查深度。

阅读代码变更#

现在您可以阅读提议的更改了。对于大型合并请求，在深入研究之前浏览更改。构建您对期待内容的理解，然后逐行阅读更改。

浏览变更获取概览#

当您首次打开 变更 页面时，首先关注更广泛的细节：

• 哪些文件发生了更改？ 展开文件浏览器 (

  ) 查看更改文件的列表。您对这些文件熟悉吗？这些文件位于代码库的哪个部分？

  

• 文件列表是否符合您的预期？ 您已经阅读了合并请求的描述。对于这种工作，您是否期望看到这些文件发生更改？请特别注意对意外文件的更改，或者如果缺少您期望看到的更改。

• 是添加、删除还是更改行？ 这些数字告诉您在更深入的阅读中期望哪种类型的工作：新功能、删除功能还是行为更改？

• 是否有任何测试被更改？ 是否有任何文件是您测试套件的一部分？如果没有，您可能需要提醒作者更新测试。

• 是否使用了功能标志？ 如果您看到功能标志，请注意在深入阅读时检查其使用。

当您完成浏览更改后，您就可以逐行阅读更改了！

深入检查每个文件#

现在您对合并请求包含的更改有了一个大致的了解。是时候深入阅读这些更改了。保持对您知识强项和弱项的意识。您对这个项目了解得很好吗？更改是用您熟悉的语言编写的吗？

• 更改是否清晰明了？
• 是否使用了功能标志？ 更改是否测试了功能标志的存在或不存在？确保功能标志的更改在标志禁用时不会意外泄露。
• 它是否具有性能？ 您是否有能力自己测试性能，或者您是否应该添加具有更深入性能知识的审查员？
• 是否可以简化？
• 它是否考虑了边缘情况？
• 是否进行了正确的注释和文档编制？ 良好的代码是可由他人而不仅仅是作者维护的。作者是否提供了足够的解释以使这项工作可维护？
• 它是否符合您团队的样式期望？
• 它是否向后兼容？ 这项工作是一个重大改变吗？它会导致数据丢失吗？
• 是否解决了安全问题？ 更改是否涉及项目中特殊安全问题的区域？它们是否适当地处理了敏感数据？它们是否接受用户输入，并且是否已进行清理？您是否应该添加具有更多安全知识的审查员？
• 是否留有任何调试语句？

不同类型的更改对您的代码库有不同的影响。请广泛考虑：

• 添加的行：新代码不应修改现有行为。新行为是否经过测试？测试是否足够细粒度？
• 删除的行：删除是否干净彻底？删除的代码和测试是否在范围上匹配？确保在任何地方都没有留下部分存根。
• 修改的行：如果添加和删除的行大致相等，这些更改是否是现有代码的重构？对于重构，您是否理解以前的代码做了什么，以及新代码如何以不同方式做到这一点？行为更改是否与作者在描述中陈述的意图相符？测试是否仍然正常工作？

测试代码#

不幸的是，我们无法在这里给您太多指导。每个项目都是不同的！在不知道您的应用程序的情况下，我们无法告诉您如何测试 更改，但我们可以提供一些需要考虑的问题：

• 它有效吗？ 这是一个看似简单的问题，但要牢记这一点很重要。代码可以是丑陋的、复杂的和无文档的，但仍然有效。

• 审查过程进展到什么程度了？ 审查过程是早期还是晚期？您是专家吗？

  • 早期的审查员应验证代码是否按作者所述工作。这可以防止更多人花时间在无法或不应合并的代码上。
  • 后期的审查员可能不会参与确保功能按预期工作，而可能更多地关注样式和可维护性。
  • 专业审查员可能只审查合并请求的某些部分，而不涉及整个合并请求是否按预期工作。

在您测试代码时，您还应该检查流水线状态。尽管您还没有写任何审查评论，但您几乎准备好了。

检查流水线#

前往合并请求的 Pipelines 选项卡，并验证流水线状态。仅当流水线成功时才批准合并请求。在此示例中，多个作业失败了：

• 所有预期测试都运行了吗？ 确保流水线不仅是绿色的，而且是完整的。
• 是否有任何测试失败？ 展开 Failed jobs 查看哪些测试（如果有）失败了。
• 每个失败作业中发生了什么？ 选择每个失败的作业。滚动浏览输出，扫描失败、错误和标记为红色的行。当您撰写审查评论时，您希望帮助作者了解需要修复的内容以及如何修复。
• 失败是否与更改相关？ 如果失败感觉无关，请考虑重新运行作业或流水线。

重新审查考虑事项#

有时合并请求审查并不简单，需要受让人与审查员之间的反复交流。如果您正在重新审查工作，请转到此合并请求的 Commits 页面，并阅读您上次审查后添加的提交内容。

这些提交是否解决了您在初始审查中的担忧？

考虑整体情况#

您现在已经为深思熟虑、有帮助的审查做好了准备。当您第一次快速浏览合并请求时，您没有对行级更改的全面了解。现在您有了！在撰写之前，从合并请求的逐行视图中退一步，再次广泛考虑它。您现在知道合并请求试图做什么，以及它如何做到这一点。

• 合并请求中的更改是否与预期范围相符？ 如果不符，问问自己这项工作是否应该简化，或者拆分为多个合并请求。诚实对待您自己的知识范围和局限性。
• 您是否检测到代码异味 如果您看到的东西不是错误，但它指向未来的质量、可维护性或安全性问题，请注意。如果对更改的某些方面感到不对劲、模糊或做得不好，请相信自己的直觉。代码可能在技术上是正确的，但包含的弱点可能会在未来导致问题。

最佳且最有帮助的代码审查不仅关注逐行修复。它们还考虑长期关注点，如可维护性和技术债务。

完成您的审查#

现在是时候提供反馈了！

当您刚开始审查合并请求时，您可能会惊讶于在写下第一条评论之前花费了多少时间思考。随着您对代码库的熟悉，您会更快地理解新的合并请求。然而，您可能也会开始承担更复杂的审查。

撰写您的审查评论#

Start a review 功能使您能够在待定评论中写下您的想法。这些评论在您提交审查之前对其他人不可见。这避免了向收件人发送过多信息，并使您有机会在发布之前重新检查（并更改）您的用词。

记住要建设性和友好。常规评论的结构可以帮助您撰写既深思熟虑又建设性的评论。

首先，撰写您想要附加到特定行或文件的评论：

1. 选择 Changes 选项卡。

2. 当您找到想要询问问题或提供反馈的行时，在边缘选择 添加注释到这一行 (

   )。这将展开差异行并显示评论框。

3. 您还可以 选择多行， 或选择整个文件进行评论：

   

4. 在文本区域中，撰写您的第一条评论。要保持评论私密直到审查结束，请在评论下方选择 开始审核。

5. 当修复很容易由您起草，或者您想向作者展示更好的方法时，请提供建议。如果代码更改太大或太复杂而无法使用建议格式，请留下请求更改的评论。

6. 继续对文件和代码的单行进行评论。每条评论后，选择 添加审核。

在您工作时，您可以在审查评论中使用 快速操作，例如 /label 或 /assign_reviewer。您的待定评论显示了您请求的操作，但在您提交审查之前不会执行这些操作。（稍后，您也可以使用 /submit_review 快速操作提交审查！）

总结您的审查#

您已经添加了文件和行特定的反馈，现在您准备总结您的审查。是时候最后一次广泛思考了。

1. 返回合并请求的 Overview 页面。
2. 扫描您的待定评论。 它们应该是有帮助的、深思熟虑的、友好的，最重要的是可操作的。您是否给作者提供了一个明显的下一步，以解决您发现的任何问题？
3. 考虑您的语气。 您是在教学、辩论还是讨论？您的评论是否实现了您的目标？如果您是作者，您会知道下一步该怎么做吗？加强良好的行为，并引导作者远离不良行为。
4. 您的评论仍然有意义吗？ 在大型合并请求中，您可能会发现某些评论不再有用，或者您以前的一些问题已经得到了解答。
5. 针对一般反馈启动线程。 确保不相关的项目没有聚集在同一评论中，以便在线程解决时，未处理的反馈不会被隐藏。可能的主题包括：
   • 将大型函数拆分为更小的单一目的函数。
   • 使用有意义的变量名称。
   • 添加更多评论以解释复杂代码。
   • 检查边缘情况和错误。
6. 为您的总结评论启动新线程。 确保您提到作者的用户名，以防他们从待办事项中工作。明确说明：
   • 您的总体发现是什么？
   • 您是否完成了审查，还是希望在完成更多工作后再次查看此合并请求？
7. 选择 提交你的审核（或使用 /submit_review 快速操作）以发布您审查中的所有评论。提交审查也会执行任何包含在这些审查评论中的快速操作。
   • 如果更改看起来不错，请选择 审批。
   • 如果更改需要更多工作，请选择 请求变更。

如果您批准合并请求并显示在审查员列表中，您的姓名旁边将显示一个绿色勾号

执行清理任务#

在您提供反馈后，整理一下。

• 确保所有待定评论都已提交。
• 更新标签和里程碑。
• 检查批准要求。
  • 合并请求中的每种类型的工作（后端、前端、文档）是否已由合适的人审查？
  • 如果需要更多审查，请提及下一个审查员的用户名，并将其添加为审查员。
• 检查合并小部件。
  • 解决您可以解决的阻碍因素，并为您无法解决的因素分配用户以帮助。
  • 添加任何需要的代码所有者进行审查。
• 此合并请求是否准备好合并？ 如果合并请求已完全审查并批准，请分配给维护者进行合并！