评审合并请求
发起评审
在发起一次分支合并请求时，建议让相关人员参与到代码审视中，以确保准合并代码的正确性。如果合并请求的目标分支为保护分支，默认会自动添加分支管理员为评审者。如需更改设置，参考保护分支规则。
评审者在完成合并请求评审之后，将会在该合并请求详情页面显示评审结果。
评审内容
评审者收到邀请评审通知后，对代码进行评审的内容一般会聚焦于以下两点：
- 该合并请求的标题、描述及关联资源是否对代码改动作出充分说明，评审者可通过评论和发起者进行沟通确认。
- 针对提交记录对应的文件改动，进行代码行级评审（评论）。
开始评审
在「合并请求」的「文件改动」页签，代码评审者可以针对代码文件进行逐行评论以完成评审。
鼠标悬停在代码文件中的某一行，点击界面中的蓝色 + 号填写评论。
直接评论
点击“评论”按钮则直接发布该评论。
代码建议
代码建议功能可以让评审者直接上手修改合并请求中的代码，告别与提交者之间反复沟通代码应该如何修改。
合并请求发起者点击“应用建议”按钮后，将直接在源分支上提交新代码覆盖旧有内容。
代码建议发布成功之后，评论内容和评审状态会同步至合并请求概览页面的活动日志。
仅合并请求发起者才能够点击“应用建议”。
会议评审
评审合并请求时支持一键发起腾讯会议，快速和与会者对齐合并内容能够促进生产与提高沟通效率。
授权访问及邀请与会人入会的方法可以参考快速发起腾讯会议。
评审进度
当需要评审多个代码文件时，可在评审完一个文件之后点击「已查看」进行跟踪与标记，文件查看进度条会随之自动更新。
文件「已查看」并不影响评审状态，仅用于跟踪文件查阅进度，且只针对当前用户生效。
完成评审
评审过程中相关代码建议仅自己可见。待所有代码文件均已被评审之后，点击右上角「完成评审」发布评审结果供其他成员参考。
「完成评审」按钮上的数字代表当前页面所有代码评论的数量。
- 「评论」：必需填写评论。评论内容为填写内容。
- 「允许合并」：可不输入评论，直接发布评审结果为：「允许合并」。
- 「需要改进」：可不输入评论，直接发布评审结果为：「需要改进」。
完成评审之后，评论内容或评审结果会同步显示在合并请求概览页面的活动日志。若合并请求的目标分支为保护分支，将会显示合并请求的评审状态（只要存在「需要改进」的评审结果，评审状态即为不通过）。
检查合并状态
除了上述常见的人工代码审查外，结合 CODING 持续集成，我们还提供了自动化代码评审工具集成的解决方案。基于预定义的规则先行对代码进行扫描，当代码质量有问题时会拒绝合并代码。只有通过了自动化工具检查的代码才允许合并，显著提高代码审查效率。
开启状态检查
仅保护分支支持开启状态检查。勾选之后，要求状态检查（CI 任务）全部运行通过后才允许合并。在持续集成中的触发规则内需要选中「创建合并请求时触发构建」，这样才能在创建合并后立即触发构建任务。
查看状态检查结果
完成上述设置后，在正确触发构建任务的情况下，可以看到合并检查的状态。如果没有显示如图界面，可能是没有在 CI 构建任务中选择「创建合并请求时触发构建」。
你可以点击右上角的刷新按钮随时获取最新状态，成功后会在下方出现分支已经合并的提示，失败则会拒绝合并。状态检查有四种状态：
- 进行中：你可以耐心地等待构建完成。
- 成功：此时合并请求可以正常合并。
- 失败：构建过程发生错误，合并检查不通过，你可以修改代码、推送触发新的构建任务直到构建成功完成。
- 异常：构建过程发生了异常，可以尝试进行手动触发。
如果存在多个状态检查的情况下，只有所有的状态检查都成功通过后才会允许分支合并。你也可以在代码浏览、提交历史、分支列表中查看状态检查过程。
在新建合并请求或合并请求合并前，开发者可更新标题和描述，添加其他项目成员为评审者，并关联项目内资源（如任务、文件、合并请求、Wiki）。你还可以通过 CI 插件自动添加评审者。
如果合并请求的目标分支为保护分支，且为保护分支配置了管理员并开启「自动添加分支管理员为评审者」，对应授权数量的分支管理员会自动添加为评审者。
2023-10-25最近更新在阅读中是否遇到以下问题？*
您希望我们如何改进？*
如果您希望得到回复，请留下您的邮箱地址。
