目录
1、前言
2、角色权限
3、强制代码审查
一、设置受保护分支
二、创建及批核Merge Request
三、历史查询
团队目前在日常开发工作中都是在线下进行代码审查,但是这样的模式根本无法做到过程留痕。因此,需要使用GitLab的Merge Request或者Gerrit这样的工具进行过程管理。这里详述一下如何通过Merge Request进行线上的代码审查。
首先,在GitLab中的角色分为以下5种:Guest、Reporter、Developer、Maintainer、Owner。具体权限可以参考官方文档
Permissions and roles | GitLab
具体的权限可以参考以下:
Action | Guest | Reporter | Developer | Maintainer | Owner |
Create new issue | ✓ 1 | ✓ | ✓ | ✓ | ✓ |
Create confidential issue | ✓ 1 | ✓ | ✓ | ✓ | ✓ |
View confidential issues | (✓) 2 | ✓ | ✓ | ✓ | ✓ |
Leave comments | ✓ 1 | ✓ | ✓ | ✓ | ✓ |
See related issues | ✓ | ✓ | ✓ | ✓ | ✓ |
See a list of jobs | ✓ 3 | ✓ | ✓ | ✓ | ✓ |
See a job log | ✓ 3 | ✓ | ✓ | ✓ | ✓ |
Download and browse job artifacts | ✓ 3 | ✓ | ✓ | ✓ | ✓ |
View wiki pages | ✓ 1 | ✓ | ✓ | ✓ | ✓ |
Create and edit wiki pages | ✓ | ✓ | ✓ | ||
Delete wiki pages | ✓ | ✓ | |||
View license management reports | ✓ 1 | ✓ | ✓ | ✓ | ✓ |
View Security reports | ✓ 1 | ✓ | ✓ | ✓ | ✓ |
View project code | ✓ | ✓ | ✓ | ✓ | |
Pull project code | ✓ | ✓ | ✓ | ✓ | |
Download project | ✓ | ✓ | ✓ | ✓ | |
Assign issues | ✓ | ✓ | ✓ | ✓ | |
Assign merge requests | ✓ | ✓ | ✓ | ||
Label issues | ✓ | ✓ | ✓ | ✓ | |
Label merge requests | ✓ | ✓ | ✓ | ||
Create code snippets | ✓ | ✓ | ✓ | ✓ | |
Manage issue tracker | ✓ | ✓ | ✓ | ✓ | |
Manage labels | ✓ | ✓ | ✓ | ✓ | |
See a commit status | ✓ | ✓ | ✓ | ✓ | |
See a container registry | ✓ | ✓ | ✓ | ✓ | |
See environments | ✓ | ✓ | ✓ | ✓ | |
See a list of merge requests | ✓ | ✓ | ✓ | ✓ | |
Manage related issues | ✓ | ✓ | ✓ | ✓ | |
Lock issue discussions | ✓ | ✓ | ✓ | ✓ | |
Create issue from vulnerability | ✓ | ✓ | ✓ | ✓ | |
View Error Tracking list | ✓ | ✓ | ✓ | ✓ | |
Pull from Maven repository or NPM registry | ✓ | ✓ | ✓ | ✓ | |
Publish to Maven repository or NPM registry | ✓ | ✓ | ✓ | ||
Lock merge request discussions | ✓ | ✓ | ✓ | ||
Create new environments | ✓ | ✓ | ✓ | ||
Stop environments | ✓ | ✓ | ✓ | ||
Manage/Accept merge requests | ✓ | ✓ | ✓ | ||
Create new merge request | ✓ | ✓ | ✓ | ||
Create new branches | ✓ | ✓ | ✓ | ||
Push to non-protected branches | ✓ | ✓ | ✓ | ||
Force push to non-protected branches | ✓ | ✓ | ✓ | ||
Remove non-protected branches | ✓ | ✓ | ✓ | ||
Add tags | ✓ | ✓ | ✓ | ||
Cancel and retry jobs | ✓ | ✓ | ✓ | ||
Create or update commit status | ✓ | ✓ | ✓ | ||
Update a container registry | ✓ | ✓ | ✓ | ||
Remove a container registry image | ✓ | ✓ | ✓ | ||
Create/edit/delete project milestones | ✓ | ✓ | ✓ | ||
View approved/blacklisted licenses | ✓ | ✓ | ✓ | ✓ | ✓ |
Use security dashboard | ✓ | ✓ | ✓ | ||
Dismiss vulnerability | ✓ | ✓ | ✓ | ||
Apply code change suggestions | ✓ | ✓ | ✓ | ||
Use environment terminals | ✓ | ✓ | |||
Run Web IDE’s Interactive Web Terminals | ✓ | ✓ | |||
Add new team members | ✓ | ✓ | |||
Push to protected branches | ✓ | ✓ | |||
Enable/disable branch protection | ✓ | ✓ | |||
Turn on/off protected branch push for devs | ✓ | ✓ | |||
Enable/disable tag protections | ✓ | ✓ | |||
Rewrite/remove Git tags | ✓ | ✓ | |||
Edit project | ✓ | ✓ | |||
Add deploy keys to project | ✓ | ✓ | |||
Configure project hooks | ✓ | ✓ | |||
Manage Runners | ✓ | ✓ | |||
Manage job triggers | ✓ | ✓ | |||
Manage variables | ✓ | ✓ | |||
Manage GitLab Pages | ✓ | ✓ | |||
Manage GitLab Pages domains and certificates | ✓ | ✓ | |||
Remove GitLab Pages | ✓ | ✓ | |||
View GitLab Pages protected by access control | ✓ | ✓ | ✓ | ✓ | ✓ |
Manage clusters | ✓ | ✓ | |||
Manage license policy | ✓ | ✓ | |||
Edit comments (posted by any user) | ✓ | ✓ | |||
Manage Error Tracking | ✓ | ✓ | |||
Switch visibility level | ✓ | ||||
Transfer project to another namespace | ✓ | ||||
Remove project | ✓ | ||||
Delete issues | ✓ | ||||
Force push to protected branches 4 | |||||
Remove protected branches 4 | |||||
View project Audit Events | ✓ | ✓ | |||
View project statistics | ✓ | ✓ | ✓ | ✓ | |
View Insights charts | ✓ | ✓ | ✓ | ✓ | ✓ |
从上图可以看出来,Maintainer能够push代码到受保护分支,而Developer只能创建Merge Request,这就为团队推行强制代码审查并做到有迹可循提供了技术保证。
通过菜单 Project -> Settings -> Repository -> Protected Branches,然后按照下图步骤设置,最终可以得到第十步的结果:
我们把本地修改的代码提交到个人远程分支上,并想把个人分支合并到某个Dev分支上用于SIT提测即可参考以下步骤。这里用从dev_sp16_man 合并到 Dev_Sprint16_Kid 作为例子。
第一步:Team1_Dev(开发人员)创建MR并提交,MR主要填写以下5个参数:(同步你可以根据团队情况选择勾选【remove source branch when merge request is accepted】)
Title
Description
Assignee
Source branch
Target branch
第二步:Team1_Leader登录,在【Merge Request】的角标已经提醒有一个request需要审核。
然后,在点击该merge request后,可以通过GitLab自带的Web IDE或者下载到本地IDE进行查看。
第三步:在代码审核无误后,可以添加comment并点击【Merge】进行代码合并,可以看到这时候的左上角状态仍然是【Open】。
第四步:在点击【Merge】后,可以看到代码合并已经成功,这时候左上角状态变为【Merged】。
三、历史查询
通过菜单 Project 选择你想进入的项目,然后点击【Merge Request】,然后再点击【All】即可展示所有的代码审查历史,这样就能在流程层面保证所有的代码合并是经过审核的,并可以做到有迹可循。