研发团队如何使用Gitlab进行代码review

最新推荐文章于 2024-12-28 09:49:15 发布

微技术

最新推荐文章于 2024-12-28 09:49:15 发布

阅读量1.2k

点赞数

CC 4.0 BY-SA版权

文章标签： gitlab

原文链接：https://mp.weixin.qq.com/s?__biz=MzkzNjQzOTE3Nw==&mid=2247490623&idx=1&sn=4f44dbe983f14f894db9472a916effcc&chksm=c3093b5a9415d975e34f09690aa3247191183f84f9a89118526204248069ee6411d2e3f34aa1&scene=126&sessionid=0

本文介绍了如何在团队中建立基于GitLab的代码审查流程，包括分支命名规范、commitmessage标准、角色设置、分支保护以及详细的代码审查步骤，旨在提升代码质量和团队协作效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

代码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流程，希望对团队研发协作有一定参考价值，也欢迎一起探讨、交流。