• 帮助文档

# 为什么要 code review？

公司的研发团队早在 svn 版本控制时就已经有 review 的习惯，理由自然不用多说。

  • 检查整个团队的编码风格是否统一
  • 有高手能对自己的代码指点一二，从而提高编码水平
  • 减少低级错误的出现
  • 约束自己写高质量的代码
  • review 的人和被 review 的人很轻松的交互，而且还能保存交互的历史等等

# 工蜂 Git 的 review 设置（非必须设置项）

评审规则主要是以目标分支的设置为主，以下 MR 代表合并请求，CR 代表代码评审

  • 创建 MR/CR 的时候如果目标分支是保护分支，则该 MR/CR 会默认继承此保护分支所在的保护分支规则组的评审人规则、必要评审人评审规则设置；
  • 创建 MR/CR 的时候如果目标分支是非保护分支，则该 MR/CR 会默认继承此项目非保护分支评审规则的评审人规则、必要评审人评审规则设置。
  • 创建 MR/CR 的时候如果目标分支是保护分支，且需要评审的文件路径匹配了保护分支设置的路径评委规则，则评审人和必要评审人会自动加上路径评委规则中配置的评审人和必要评审人。若路径评审中设置了必要评审人，必要评审人规则会默认选中全部必要评审人同意，非保护分支也同理。

下面以保护分支的设置为例，非保护分支的设置入口在 项目设置-->分支规则（含保护分支）-->非保护分支个评审规则

# 进入保护分支的设置页

Code review 的设置是针对目标分分支的，首先把 MR 的目标分支设置保护分支，然后再进入保护分支的设置界面。

目前保护分支都被集合在保护分支规则组当中，可根据不同需要配置不同的保护分支规则组。

入口：项目设置-->分支规则（含保护分支）-->保护分支规则组-->对应分支的规则组

cr_protectbranch

# 对保护分支的 merge 操作和 push 操作设置权限

进入到分支规则组编辑页之后，点击允许合并操作或者允许推送操作下拉框进行设置

cr_protectbranch_set

# 保护分支规则组成员设置
  1. 进入到项目设置 - 分支规则（含保护分支）页面，选择需要修改的保护分支规则组，点击后面的编辑规则组；

cr_protectbranch

  1. 鼠标拉到页面的最下方，点击右下角的新增成员。那么这里添加的用户就是分支规则组成员了，如果已经添加了的成员，也会显示在这里。

cr_protectbranch_member_add


Ps: 保护分支规则组成员的权限只针对这个分支哦~

# Review 特性设置

cr_feature

  • 特性 1：勾选后，合并请求 OK 状态下再在 source branch 上提交 commit 后 review 状态重置为需要重新评审，不勾选则没有该效应;
  • 特性 2：勾选后，合并请求/代码评审的创建者不能通过自己创建的合并请求/代码评审
  • 特性 3：勾选后，在对应的分支上进行提交后会根据预置好的评审规则自动创建一个代码评审
  • 特性 4：勾选后，创建评审时，项目权限在 master 以下的成员不能修改预置的评审规则，master 及以上权限的成员可以修改评审规则。
# 评审规则

  • 评审角色 建议评委：填写后创建 review 会自动成为 reviewer 且可以被移除; 必要评审人：填写后创建 review 会自动成为 necessary_reviewer，master 权限以下的用户不能移除他们

  • 评审规则 目前评审人规则和必要评审人规则是评审人包含必要评审人，评审人和必要评审人按规则都要通过后，评审才能通过。 cr_rules

  1. 评审人规则：

    • 单评审人同意即通过：即只需要一个评审人通过该 mr 就可以通过
    • 需要全部评审人同意：即需要所有的评审人通过该 mr 才能通过
    • 需要指定个数的评审人同意：即可以指定 0-100 个数的评审人通过，当通过评委数达到指定要求时，该 mr 才能通过。

  2. 必要评审人规则：

    • 不需要必要评审人即可通过：即按照评审人规则通过后，不需要必要评审人通过，该 mr 就可以通过
    • 需要至少一个必要评审人同意：即按照评审人规则通过后，至少需要一位必要评审人通过，该 mr 才可以通过
    • 需要全部必要评审人同意：即按照评审人规则通过后，需要全部必要评审人同意，该 mr 才可以通过
    • 需要指定个数的必要评审人同意：即按照评审人规则通过后，需要指定个数的必要评审人通过后，该 mr 就可以通过
# 路径评委规则

cr_rules_path

例如：*.js review reviewer=username1,username2 这个写法意思是：匹配到后缀为 js 的文件有改动时，username1,username2 本不是评委的，也会加到这个 mr 的评委中。

路径规则可以是正则表达式，可参考 git 的PATTERN FORMAT

Ps:创建评审时，当评审的文件路径匹配中了路径评委规则的配置的时候，会自动把设置的 reviewer 填充到评审人（可删除）选项中，同时把设置的 necessary_reviewer 填充到必要评审人（不可删除）选项中。

# 如何发起 code review？

目前工蜂既支持基于 MR 的评审，又支持代码提交后的评审。

# 基于代码提交后的评审

  • 代码提交后的评审提供了基础版和高级版，基础版适合单分支开发的评审，高级版则适合跨分支和跨项目的评审。
  • 基础评审规则继承该分支的评审设置，高级评审规则继承目标分支的评审设置。
  • 基于代码提交后的评审新建之后不管有没有添加评委，新建即是 CR，评审方式可参考基于 MR 的评审,不过 CR 没有合并的操作。
# 基础评审

代码提交后基础评审只能评审当前项目的某个分支。

  1. 入口：登录 git.tencent.com-找到我的项目-->任务-->代码评审-->创建代码评审-->基础

  2. 选择评审分支以及评审范围 评审范围可以选择选中分支中需要评审的提交点，假设当前分支有 a1、a2、a3、a4、a5、a6...... 等提交。 总共需要选择两次，第一次选择的是源提交点，第二次选择的是目标提交点 （此时比较是源提交点与目标提交点之间的文件，目前工蜂使用的三个点的对比，也就是 git diff a...b, 不过由于现在是同一个分支，此时选择的两个提交点对比，底层其实也是直接对比这两个提交点的文件。 cr_create

  3. 输入标题等点击提交 其他：

  • 发起人不可自己通过评审。此设置当前页面不可修改，可以在项目设置的代码评审中或者保护分支设置里面修改
# 高级评审

代码提交后高级评审即能评审某一分支的提交，又可以评审跨分支和跨项目的提交。 高级评审提供源项目、源项目分支、源项目分支提交点和目标项目、目标项目分支、目标项目分支提交点的选择，同时源项目和目标项目都可以是当前项目 fork 的项目，非常灵活。

  1. 入口：登录 git.tencent.com-找到我的项目-->任务-->代码评审-->创建代码评审-->高级

  2. 选择评审分支以及评审范围 cr_create

  3. 输入标题等点击提交
    cr_create

其他：

  • 发起人不可自己通过评审。此设置当前页面不可修改，可以在项目设置的代码评审中或者保护分支设置里面修改；
  • 创建合并请求。当源分支与目标分支的项目/分支不同，且提交点都是分支的第一个提交点时可勾选。

# 基于 MR 的评审

创建 MR 的时候也可以添加评审人和必要评审人，创建成功后，这个 MR 就是一个 CR，评审人和必要评审人会收到企业微信和邮件通知，同时也会出现在项目的评审列表中。 创建 MR 的时候未添加评审人或者必要评审人，创建成功后，这个 MR 并不算是一个 CR，不会出现在项目的评审列表中。

编辑 MR 时不可以修改评审人规则，但可以添加评审人/必要评审人，以及删除评审人。

# 创建 MR

每个独立的项目我们系统会默认有一个 master 分支，可以理解为用于发布的稳定分支。在 master 基础上，我们可以创建自己的需求分支 等到开完成就可以发起一个 merge request 了。以我的项目为例：我在本地创建了一个名为“1227”的分支

  • master（不会被删除）
  • 1227

假设开发任务已经完成并且已 push 到我自己的分支上，这时候我就可以来发起一个 MR 了。 入口：登录 git.tencent.com-找到我的项目-->合并请求-->创建合并请求

# 添加评委

如果目标分支的代码评委有设置必要的评委和建议评委，那么必要的评委和建议评委都将自动填上，我们也可以在 MR 创建之后在页面上邀请评委。 cr_mr_reviewer

# 查看 diff 并发表评论

  • 单栏模式 直接进入变更页查看 diff 并评论即可 cr_mr_comment

  • 经典模式 相对与单/双栏模式来讲，经典模式多了可以搜索文件、选择只看某两个提交点之间的 diff、查看 diff 上下文等功能

假设当前评审 a1、a2、a3、a4、a5、a6...... 等提交，在经典模式的选择提交按钮中可以选择评审中的若干提交点。 比如我第一次选择了 a2 提交，第二次选择了 a5 提交，则经典模式文件列表会出现 a2、a3、a4、a5 变更的文件文件。这对于想要缩小提交评审范围是一个非常方便的操作。

a.切换经典模式
cr_mr_style
b.选择提交，查看 diff
cr_mr_commits
c.查看上下文，评论 diff cr_mr_diff

# CodeReview 的流转状态

review changes 一共分为四种状态：

  • 评论
  • 同意
  • 反馈修改
  • 拒绝
    cr_mr_status

评委表态之后对应的状态为：

  • review required：review 创建后的初始状态，当有评委只发表 comment 时显示的状态
  • review approved：当所有评委 approve 之后的状态
  • change required：当有评委驳回修改之后的状态，CR 将要重新 reopen
  • change denied：当有评委拒绝本次 CR 时的状态，CR 将要重新 reopen

cr_status

# 评审状态
  • 目前评审有评审中、请求更改、评审通过、评审关闭四中状态
  • 评审中：表明此时评审人评审的要求还未符合评审人规则和必要评审人规则
  • 请求更改：表明评审人需要评审创建者再次修改代码，可以重新打开（reopen）把状态变成评审中状态
  • 评审通过：表明评审人评审的要求符合了评审人规则和必要评审人规则
  • 评审关闭：表明不再希望这个评审继续评审下去了
# 合并合并请求

当代码评审状态改为通过评审时，说明该代码评审已经通过评审; 合并请求的状态会变成可合并状态，这个时候可以按需选择合并方式将开发分支的修改合并到 master 上。
cr_mr_merged

还有更多的评审小技巧，点击获取详情

lastUpdate: 9/27/2024, 4:00:26 PM

← 如何做提交前 CodeReview →