利用GitLab对代码的Merge进行事前管理

Posted 2021-06-29 娃都会打酱油了

作为开发，CodeReview是一个绕不过去的事情，但每次问到如何做CodeReview这个事情，答案大同小异：“抽时间对主要代码进行检查”、“组织会议大家一起检查”等等，但这些Review真的是有效Review吗？个人对这个答案是否定的，CodeReview是什么意思？是代码审查，都已经合并到主分支了，这还叫代码审查吗？这叫白盒测试，是大家一起来找茬！！CodeReview的作用应该是阻止有问题的代码合并进入主分支，所以最重要的点是这件事情要做在合并前，做到预防！

那用GitLab如何做到事前预防呢？其实很简单，禁止所有人员直接推送代码到受保护的分支，只允许特定人员进行Merge，这些特定人员就是CodeReview人员，下面我们就来说明下具体应该怎么做。

打开GitLab上的任意一个项目，依次点击“Settings–Repository–Protected Branches”

可以看到默认master分支是受保护的分支，“Allow to merge”表示谁可以进行合并，可以按角色设置，也可以直接指定到用户，“Allow to push”表示谁可以进行代码推送，将“Allow to push”设置为“No one”就可以禁止所有用户直接在这个受保护的分支上提交代码，将“Allow to merge”设置为指定角色或人员，这些人一般情况下就是负责进行CodeReview的人员。当然你也可以将master以外的分支也设置为受保护的分支，只需在上方选择相应分支，然后选择哪些人可以Merge和哪些人可以Push，然后点击“Protect”按钮即可，比如下图就添加了dev分支作为受保护的分支。

在上图中，我们可以看到在master分支旁边有个default标签，这个是当开发人员提交Merge请求时，默认选择的目标分支，可以通过“Settings–Repository–Default Branch”来进行设置。

默认情况下，开发人员发起Push时，可以不填写“Commit Message”，但一般情况下我们都要求开发人员对此次提交进行一个概要性说明，此时我们可以强制要求开发人员填写提交说明，路径为“Settings–Repository–Push Rules”，可以看到可以通过正则来限定提交说明和分支名称等，也可以限定哪些邮箱地址可以进行提交，这可以有效预防开发人员错误的以其它git账号信息进行提交。

上面说了如何对分支进行保护，下面说下如何Merge。依次点开“Settings–General”，然后有“Merge requests”和“Merge request approvals”这两块是和Merge有关的。“Merge requests”对应的是合并时的一些配置，你可以按需进行调整，如下图：

“Merge request approvals”和上面说到的“Allow to merge”人员对应，如果“Allow to merge”不是真正的CodeReview人员，那么“Merge request approvals”这块就可以来设置真正的CodeReview人员，你可以设置至少要几个人同意之后才可以进行Merge。

在上述设置都完成之后，开发人员想要提交代码，就必须要在“Merge Requests”内发起代码Merge请求。

如果你是单个Push进行Merge，那默认创建合并请求时，就会以该请求的Commit Message作为Merge的Title，如果你是多个Push进行Merge，那默认的Merge Title就会为你的分支名称，你可以选择哪些人员进行通知，这样这些人登录Gitlab时，就能在右上角看到对应的消息图标，如果git还设置了邮件通知的话，Gitlab还会发一份通知邮件到相应邮箱。

当开发人员提交Merge请求后，相应的审核人员就可以在“Merge Requests”内进行CodeReview了。

上图中我们已经打开了一个Merge请求，点开“Changes”就可以对修改的内容进行审核，如果对某些代码存在疑问或建议，可以在相应代码上进行Review并提交建议。

当然如果你觉得这些东西直接就可以手工改掉，那么也可以直接通过点击文件右侧的“option–Edit”进行修改。

以“Edit in single-file editor”为例，你可以直接修改完后就进行提交。

GitLab也能做CI/CD之类的事情，感兴趣的同学可以去了解下，毕竟上面虽然阻止了开发人员直接提交代码，但开发人员提交的代码理论上应该是必须要能够编译通过才行，而CodeReview人员不是编译器，无法做到仅通过CodeReview就保证编译通过，所以这时候就需要CI/CD来保证了。