为什么要code review？
检查整个团队的编码风格是否统一
有高手能对自己的代码指点一二，从而提高编码水平
减少低级错误的出现
约束自己写高质量的代码
review的人和被review的人很轻松的交互，而且还能保存交互的历史等等
Git的review设置（非必须设置项）
评审规则主要是以目标分支的设置为主,以下 MR 代表合并请求，CR 代表代码评审
创建 MR/CR 的时候如果目标分支是保护分支，则该 MR/CR 会默认继承此保护分支的评审人规则、必要评审人评审规则设置。
创建 MR/CR 的时候如果目标分支是非保护分支，则该 MR/CR 会默认继承此项目的评审人规则、必要评审人评审规则设置。
创建 MR/CR 的时候如果目标分支是保护分支，且需要评审的文件路径匹配了保护分支设置的路径评委规则，则评审人和必要评审人会自动加上路径评委规则中配置的评审人和必要评审人。若路径评审中设置了必要评审人，必要评审人规则会默认选中全部必要评审人同意，非保护分支也同理。
下面以保护分支的设置为例，非保护分支的设置入口在 项目设置-高级设置-代码评审。
进入保护分支的设置页
Code review的设置是针对目标分分支的，首先把 MR 的目标分支设置保护分支，然后再进入保护分支的设置界面。
导航至入口 项目设置-保护分支-具体的保护分支设置。
对保护分支的merge操作和push操作设置权限
比如：Above Master+Branch Member（Except Reporters）即项目权限为 master 或 master 以上+分支成员（reporters权限除外）;
Branch member 需额外配置，配置方法可参考文档中的保护分支成员设置内容。（这些权限都需要去除分支成员中的repoter）
保护分支成员设置
进入到项目设置的保护分支页面，选择一个已经受保护的分支，点击后面的设置
鼠标拉到页面的最下方，右下角有一个添加成员的按钮。那么这里添加的用户就是分支成员了，如果已经添加了的成员，也会显示在这里。
注意： 保护分支成员的权限只针对这个分支。
review特性设置
特性1：勾选后，合并请求OK状态下再在源分支上提交后，评审状态重置为需要评审，不勾选则没有该效应。
特性2：勾选后，合并请求的创建者不能被添加到评委中。
特性3：勾选后，在对应分支上有任何提交都会新建一个评审单。
评审规则
评审角色
建议评委： 填写后创建review会自动成为reviewer且可以被移除。
必要评审人：填写后创建review会自动成为necessary_reviewer，但是不能被移除。
评审规则
目前评审人规则和必要评审人规则是评审人包含必要评审人，评审人和必要评审人按规则都要通过后，评审才能通过。
评审人规则
单评审人同意即通过：即只需要一个评审人通过该mr就可以通过。
需要全部评审人同意：即需要所有的评审人通过该mr才能通过。
需要指定个数的评审人同意：即可以指定0-100个数的评审人通过，当通过评委数达到指定要求时，该mr才能通过。
必要评审人规则
不需要必要评审人即可通过：即按照评审人规则通过后，不需要必要评审人通过，该mr就可以通过。
需要至少一个必要评审人同意：即按照评审人规则通过后，至少需要一位必要评审人通过，该mr才可以通过。
需要全部必要评审人同意：即按照评审人规则通过后，需要全部必要评审人同意，该mr才可以通过。
需要指定个数的必要评审人同意：即按照评审人规则通过后，需要指定个数的必要评审人通过后，该mr就可以通过。
路径评委规则
例如：*.js review reviewer=username1,username2 表示，匹配到后缀为js的文件有改动时，username1,username2本不是评委的，也会加到这个mr的评委中。
路径规则可以是正则表达式，可参考git的PATTERN FORMAT
创建评审时，当评审的文件路径匹配中了路径评委规则的配置的时候，会自动把设置的reviewer填充到评审人（可删除）选项中，同时把设置的necessary_reviewer填充到必要评审人（不可删除）选项中。
如果同时路径评委规则中又设置了必要评审人，则页面上必要评审人规则默认会选中需要全部必要评审人同意，而忽略保护分支和项目设置里面的必要评审人规则。
如何发起code review？
目前既支持基于 MR 的评审，又支持代码提交后的评审。
基于代码提交后的评审
代码提交后的评审提供了基础版和高级版，基础版适合单分支开发的评审，高级版则适合跨分支和跨项目的评审。
基础评审规则继承该分支的评审设置，高级评审规则继承目标分支的评审设置。
基于代码提交后的评审新建之后不管有没有添加评委，新建即是 CR ，评审方式可参考基于MR的评审,不过CR没有合并的操作。
基础评审
代码提交后基础评审只能评审当前项目的某个分支。
新建基础CR
导航至项目-任务-代码评审-创建代码评审-基础
选择评审分支以及评审范围
评审范围可以选择选中分支中需要评审的提交点，假设当前分支有a1、a2、a3、a4、a5、a6...... 等提交。
总共需要选择两次，第一次选择的是源提交点，第二次选择的是目标提交点。
注意：此时比较是源提交点与目标提交点之间的文件，目前使用的三个点的对比，也就是git diff a...b。 不过由于现在是同一个分支，此时选择的两个提交点对比，底层其实也是直接对比这两个提交点的文件。
输入标题等点击提交
注意：上图中的其他选项表明，发起人不可自己通过评审。此设置当前页面不可修改，可以在项目设置的代码评审中或者保护分支设置里面修改。
高级评审
代码提交后高级评审即能评审某一分支的提交，又可以评审跨分支和跨项目的提交。
高级评审提供源项目、源项目分支、源项目分支提交点和目标项目、目标项目分支、目标项目分支提交点的选择，同时源项目和目标项目都可以是当前项目fork的项目，非常灵活。
新建高级CR
导航至项目-任务-代码评审-创建代码评审-高级
选择评审分支以及评审范围
输入标题等点击提交
注意：上图中的其他选项表明
- 发起人不可自己通过评审。此设置当前页面不可修改，可以在项目设置的代码评审中或者保护分支设置里面修改。
- 创建合并请求。 当源分支与目标分支的项目/分支不同，且提交点都是分支的第一个提交点时可勾选。
基于MR的评审
创建MR的时候也可以添加评审人和必要评审人，创建成功后，这个MR就是一个CR，评审人和必要评审人会收到企业微信和邮件通知，同时也会出现在项目的评审列表中。
创建MR的时候未添加评审人或者必要评审人，创建成功后，这个MR并不算是一个 CR，不会出现在项目的评审列表中。
注意：编辑MR时不可以修改评审人规则，但可以添加评审人/必要评审人，以及删除评审人 。
创建MR
每个独立的项目我们系统会默认有一个master分支，可以理解为用于发布的稳定分支。在master基础上，我们可以创建自己的需求分支。 等到开完成就可以发起一个MR了。以我的项目为例：我在本地创建了一个名为 "a" 的分支，此时项目有两个分支，分别是：
分支master（不会被删除）
分支a
假设开发任务已经完成并且已提交到我自己的分支上，这时候我就可以来发起一个 MR 了。导航至项目-合并请求-创建合并请求。
源分支选择 a , 目标分支选择 master ,点击比较两分支，然后在下图中输入标题，页面拉到下方点击提交，这个 MR 就创建成功了。
添加评委
如果目标分支的代码评委有设置必要的评委和建议评委，那么必要的评委和建议评委都将自动填上，我们也可以在 MR 创建之后在页面上邀请评委。
查看diff并发表评论
单栏模式
直接进入变更页查看diff并评论即可。
经典模式
相对与单/双栏模式来讲，经典模式多了可以搜索文件、选择只看某两个提交点之间的diff、查看diff上下文等功能。
注意：
- 假设当前评审a1、a2、a3、a4、a5、a6...... 等提交，在经典模式的选择提交按钮中可以选择评审中的若干提交点。
- 比如我第一次选择了a2提交，第二次选择了a5提交，则经典模式文件列表会出现a2、a3、a4、a5变更的文件文件。这对于想要缩小提交评审范围是一个非常方便的操作。
切换经典模式
选择提交，查看diff
查看上下文，评论diff
code review的流转状态
review changes一共分为四种状态：
评论
同意
反馈修改
拒绝
评委表态之后对应的状态为：
review required：review创建后的初始状态，当有评委只发表comment时显示的状态。
review approved：当所有评委approve之后的状态。
change required：当有评委驳回修改之后的状态，CR将要重新reopen。
change denied：当有评委拒绝本次CR时的状态，CR将要重新reopen。
评审状态
目前评审有评审中、请求更改、评审通过、评审关闭四中状态。
评审中：表明此时评审人评审的要求还未符合评审人规则和必要评审人规则。
请求更改：表明评审人需要评审创建者再次修改代码，可以重新打开（reopen）把状态变成评审中状态。
评审通过：表明评审人评审的要求符合了评审人规则和必要评审人规则。
评审关闭：表明不再希望这个评审继续评审下去了。
合并合并请求
当评审状态改为通过评审时，说明该 MR 的评审已经通过评审完成。
合并请求的状态会变成
同意合并代码请求状态，这个时候可以将开发分支的修改合并到master上了。
