研发团队如何使用Gitlab进行代码review
研发团队如何使用Gitlab进行代码review
代码Review是保障代码质量的重要手段，也是团队成员间技术交流的有效方式。本文将分享一种基于Gitlab的代码merge流程，帮助团队建立规范的代码Review机制。
一、开发规范
1. 分支命名规范
名称 | 说明 | 命名规范 | 命名示例 | 目标 | 合并操作 |
|---|---|---|---|---|---|
master | 线上稳定版本，发布需要打Tag。 | master | master | - | - |
test | 测试分支，待发布版本。 | test | test | master | merge request |
dev | 当前正在开发的分支 | dev | dev | test | merge request |
feature | 功能分支，每个功能需分别建立自己的子分支 | feature-功能模块 | feature-order | dev | merge request |
2. CommitMessage 规范
Git提交代码必须输入commit message，否则不允许提交。commit message应该尽量清晰明了，说明本次提交的目的。关于commit message写法规范，我们将采用社区使用最广的angular规范，比较合理和系统化，并且有配套的工具。
commit message格式
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header
(1) type用于说明commit的类别，常用的标识如下，
- feat：新功能
- fix：修补bug
- docs：文档
- style：格式（不影响代码运行的变动,空格,格式化,等等）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动)
- perf: 性能 (提高代码性能的改变)
- test：增加测试或者修改测试
- build: 影响构建系统或外部依赖项的更改(maven,gradle,npm 等等)
- ci: 对CI配置文件和脚本的更改
- chore：对非 src 和 test 目录的修改
- revert: Revert a commit
(2) scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
(3) subject是 commit 目的的简短描述，不超过50个字符，主要介绍此次代码变更的主要内容。
Body
Body 部分是对本次 commit 的详细描述，可以分成多行。
例如：
- 修改菜单查询接口
- 增加菜单删除接口
日常项目开发中，如果Header中subject已经描述清楚此次代码变更的内容后，Body部分就可以为空。
Footer
(1) 不兼容变动
(2) 关闭 Issue
日常项目中开发，Footer不常用，可为空。
3. Idea Git Commit Template插件
- 开发手册
推荐使用阿里巴巴开发手册。
二、Code Review
1. 前置代码Review
提交代码到gitlab时，主要做下面两件事情：
- 检查commit message是否合理
- 通过p3c插件检查代码质量，p3c是专门用来检测代码是否符合阿里巴巴开发规范的。
采用MergeRequest形式，合并代码时进行代码Review，或者发起Issue。
2. 设置成员角色
首先需要对你团队的成员分配角色，在Gitlab groups里选择一个group，然后左边菜单栏点击 Members，可在 Members 页面添加或编辑成员角色，如下图所示。
其中角色包含如下几类：
- Guest：权限最小，基本查看功能
- Reporter：只能查看，不能push
- Developer：能push，也能merge不受限制的分支
- Master：除了项目的迁移、删除等管理权限没有，其它权限基本都有
- Owner：权限最大，包括项目的迁移、删除等管理权限
详细权限参考：https://docs.gitlab.com/ee/user/permissions.html
确定团队中技术水平、经验较好的成员为Master，负责代码的review与分支的合并；其他成员为Developer，提交合并请求，接受review意见；Master之间可以互相review。
3. 配置分支保护
在项目页面左侧菜单栏 Settings -> Repository， 进入“Protected Branches”部分配置分支保护，如下图所示。
在这里可以针对每个分支，设置允许什么角色可以merge，允许什么角色可以push，选项包括三个：“Masters”， “Developers + Masters”， “No one”。这里设置成只允许master可以直接push与merge这几个常设分支的代码。（如果更严格一点，可以将“Allowed to push”设置成“No one”）
4. 代码review流程
4.1. 开发（开发者负责）
- 本地切到dev分支， 拉取最新代码（相关命令如下，GUI工具操作自行查相关文档）
git branch #查看当前位于哪个分支，前面打星号即为当前分支
git checkout dev #切换到dev分支
git pull #拉取最新代码
- 从dev分支切出子分支
#从当前分支切出子分支，命名为"feature-1101"
git checkout -b feature-1101
- 编码、本地自测完之后，提交子分支到远程仓库
git add * #加入暂存区
git commit -m "commit msg" #提交到本地仓库
git push origin feature-1101 #提交到远程仓库
4.2 发起Merge请求（开发者负责）
在项目主页面，依次点击左侧“Merge Requests”（下图1），“New merge request”（下图2），打开新建Merge请求页面
在新建Merge请求页面，选择merge的源分支，及目标分支，如下图源分支为“feature-1101”，目标分支为“dev”，点击“Compare branches and continue”按钮进入对比与提交页面
- 在对比与提交页面，可以点击“Changes” tab查看本次修改（这里我为了演示，只是加了两个换行），确认无误，点击“Submit merge request”按钮，提交merge请求
提交之后，将结果页面的浏览器地址发到团队即时通讯群（如钉钉），并@相应的同事申请review
4.3 代码Review（code reviewer负责）
- 负责代码Review的同事收到申请后，点击merge请求地址，打开页面，查看“Changes”，这里可通过“Inline”单边查看，也可以通过“Side-by-side”两个版本对比查看
- review完成后，若无问题，则可点击”Merge”按钮完成merge，同时可删除对应的子分支“feature-1101”，若有问题，则可点击“Close merge request”按钮关闭该merge请求（也可以不关闭复用该merge请求），同时通知开发者进行相应调整，重新提交代码发起merge请求（如果之前没关闭merge请求，则刷新即可看到调整）。
4.4 冲突解决
- merge的时候，可能存在代码冲突，这时，开发者可从dev分支重新拉取最新代码进行本地merge， 解决冲突后重新提交代码进行review
#在当前子分支拉取dev分支的最新代码进行本地merge
git pull origin dev
# 解决冲突代码
# 提交
git add *
git commit -m "fix merge conflict"
git push origin feature-1101
- 自行解决不了时，寻求协助。
总结
团队协作，流程、规范很重要，不同的团队可能有不同的适用流程与规范。此文分享了基于Gitlab的代码review流程，希望对团队研发协作有一定参考价值，也欢迎一起探讨、交流。