如何做好 Code Review

最近公司的业务正在发展，参与的人也越来越多。但人数的增加也伴随着风险的提升，良莠不齐的人员配置，会使得代码质量难以控制。这个时候，就需要在代码入库之前，加上一道质检步骤，通过这个质检步骤，能够有限地规避一些风险。

本文以 Git 作为说明，其他 VCS 工具，原理也大致相同。

实现代码审查，现在大体有两种方式，分别是类 Gerrit 或者类 GitHub/Gitlab，这篇文章主要介绍后者。

类 Gerrit

Gerrit 是最容易实现代码审查的一种方式，它在真正仓库和开发者之间建立了一个审核区域，所有进入代码仓库的代码，都必须先通过这个审核区域。

git push origin dev/v1.0

这是最普通的提交方式，但在 Gerrit 中就不可以。

git push origin HEAD:refs/for/dev/v1.0

上面是正确的提交方式，注意到两者的区别了吗？多了一个 refs/for，这就是 Gerrit 的审核区域，只有通过审核，才能进入主仓库。这里给了一个内部实现图，有兴趣的同学可以参考，这里就不进行额外介绍了。

gerrit_workflow

类 Gitlab/Github

重点说说这类代码审查如何展开，因为现在公司使用的就是这种方案，而且 Gerrit 的颜值太低，哈哈。

权限分组

首先需要对权限进行分组，每个组的�拥有不同的权限，一般情况下分为 owner, master 和 developer。owner 拥有最高的权限，master 次之。我们用的最多的权限组就是 master 和 developer。master 能够在保护分支上直接 push，而 developer 就不能。这样通过权限的划分，就能保证属于 develop 这个组的人，�在没有代码审查的情况下不能将代码入库。

保护分支

在 Gitlab/Github 上有保护分支这个概念，当一个分支属于保护分支的时候，developer 是不能直接入代码的。

我们所进行的�工作，很多时候，都是版本迭代开发。因而会有分支去跟踪当前版本迭代。有一种比较好的划分方式，是 master / dev/version? / features/version?。 master 保存着当前最稳当的代码版本，而dev/version? 则是当前开发版本的代码，features/version? 是这个版本代码开发�feature的仓库。

developer �的权限只能在 features/version? 上进行工作。�那么如何合并代码�到 dev 分支了？就只能通过提交 Merge Request，审核通过后，�master 将代码弄到 dev 分支上去。

Merge Request

merge_request_select_branch

上图就是提交 Merge �Request 的界面。开发者可以选择自己所在的 features 分支，将相应的 commit 提交申请到 dev 分支上。master 会看到如下的界面，该界面显示�是否需要合并这个 Request。

merge request

是不是很简单？更多信息可以查看官方文档，�还有这篇博客

文档信息

版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
发表日期：2017年8月31日
社交媒体：weibo.com/woaitqs
Feed订阅：www.woaitqs.cc/feed.xml