代码review是代码质量保障的手段之一，同时开发成员之间代码review也是一种技术交流的方式，虽然会占用一些时间，但对团队而言，总体是个利大于弊的事情。如何借助现有工具在团队内部形成代码review的流程与规范，是team leader或技术管理者需要考虑的问题。本文分享一种基于Gitlab代码merge流程的code 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插件
4 开发手册
推荐使用阿里巴巴开发手册。
二 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流程，希望对团队研发协作有一定参考价值，也欢迎一起探讨、交流。
2162
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
