GitLab的权限管理及Merge Request

本文详细介绍了如何使用GitLab的MergeRequest进行线上代码审查,包括设置受保护分支、创建及批核MergeRequest的流程,以及GitLab中不同角色的权限管理。通过强制代码审查,确保团队开发过程的透明度和代码质量。

目录

1、前言

2、角色权限

3、强制代码审查

一、设置受保护分支

二、创建及批核Merge Request

三、历史查询


1、前言

团队目前在日常开发工作中都是在线下进行代码审查,但是这样的模式根本无法做到过程留痕。因此,需要使用GitLab的Merge Request或者Gerrit这样的工具进行过程管理。这里详述一下如何通过Merge Request进行线上的代码审查。

2、角色权限

首先,在GitLab中的角色分为以下5种:Guest、Reporter、Developer、Maintainer、Owner。具体权限可以参考官方文档

Permissions and roles | GitLab

具体的权限可以参考以下:

ActionGuestReporterDeveloperMaintainerOwner
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 code1
Pull project code1
Download project1
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,这就为团队推行强制代码审查并做到有迹可循提供了技术保证。

3、强制代码审查

一、设置受保护分支

通过菜单 Project -> Settings -> Repository -> Protected Branches,然后按照下图步骤设置,最终可以得到第十步的结果:

二、创建及批核Merge Request

我们把本地修改的代码提交到个人远程分支上,并想把个人分支合并到某个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】即可展示所有的代码审查历史,这样就能在流程层面保证所有的代码合并是经过审核的,并可以做到有迹可循。

转自:GitLab的权限管理及Merge Request - 滴滴滴 - 博客园

<think> 我们正在处理关于GitLab中如何打回或拒绝Merge Request的问题。根据提供的引用,我们可以总结如下: 引用[1]提到:在Merge Request过程中,等到MR被接受或拒绝,并提供有关必要修复的评论。参与有关修复的讨论。修复后,将更改推送到分支,如果最后一个MR被关闭,则打开一个新的合并请求(如果合并请求未关闭,它将自动更新直到最后一次提交)。 引用[2]中展示了一个操作流程,但并没有直接说明拒绝的方法。 引用[3]则说明:在GitLab中,对目标分支拥有merge权限的用户可以执行Merge操作完成合并。反过来,他们也可以不合并(即拒绝)或者要求修改。 因此,拒绝Merge Request通常有两种方式: 1. 关闭(Close)Merge Request:这相当于直接拒绝,不合并。拥有相应权限的用户(如项目维护者)可以在Merge Request页面点击“Close”按钮来关闭该请求。 2. 在评论中要求修改,然后由提交者自己关闭,或者等待提交者重新修改后再次提交。 另外,在代码评审过程中,评审者可以在Merge Request的讨论中提出修改意见,如果认为当前请求不应该被合并,可以明确表示拒绝合并,并要求提交者修改后重新提交。如果提交者无法完成修改或者请求被废弃,就可以关闭Merge Request。 具体操作步骤: 1. 作为评审者,打开Merge Request页面。 2. 在讨论区提出修改意见,可以@相关开发人员。 3. 如果决定拒绝合并,可以直接点击“Close merge request”按钮关闭该请求。 4. 提交者根据反馈修改代码后,可以重新推送代码到原分支(此时如果Merge Request还未关闭,则会自动更新),或者如果已经关闭,则需要重新创建一个新的Merge Request。 注意:关闭Merge Request意味着该请求不会被合并,也就是拒绝了此次合并。 因此,回答用户:在GitLab中,打回或拒绝Merge Request的方法主要是通过关闭(Close)该Merge Request来实现。同时,可以在关闭前通过评论说明拒绝的原因和需要修改的地方。 下面按照要求生成回答: </think>在 GitLab 中打回或拒绝 Merge Request 的方法如下,操作分为评审者和提交者两种角色: ### 评审者操作(拒绝/打回) 1. **添加拒绝评论** 在 Merge Request 的讨论区直接评论,明确指出问题(如代码缺陷、设计问题等),可使用 `@` 提及相关人员 ```markdown @username 第 32 行存在空指针风险,请修复后重新提交 ``` 2. **关闭 Merge Request** 点击顶部 `Close merge request` 按钮(需有权限),系统将自动: - 标记 MR 状态为 **Closed** - 发送拒绝通知给提交者 - 保留所有评论记录供后续参考 *示例操作路径:* `Merge Request 详情页 → 顶部工具栏 → Close merge request` [^3] 3. **使用 `/reject` 命令**(GitLab 15.0+) 在评论框输入: ```re /reject 因未通过安全扫描拒绝合并 ``` 系统会自动关闭 MR 并添加原因标签 [^1] ### 提交者操作(处理被拒 MR) 1. **在原有分支修复问题** ```bash git checkout feature-branch # 切换到被拒分支 git commit -m "修复空指针问题" # 修改代码 git push origin feature-branch ``` **自动更新**:若原 MR 未关闭,推送后会自动更新 MR 内容 [^2] 2. **重新提交 MR** 若 MR 已被关闭: - 在 GitLab 界面点击 `Reopen merge request` 恢复原有 MR - 或新建 MR 并关联原讨论:`New merge request → 引用原 MR !ID` [^1] --- ### 关键概念说明 | 操作 | 效果 | |---------------------|----------------------------------------------------------------------| | **Close MR** | 终止当前合并请求,代码不会合并到目标分支 | | **Reopen MR** | 重新开启已关闭的 MR(修改后可用此功能) | | **自动更新机制** | 只要源分支有新提交,关联的 MR 会自动同步更改(除非被关闭)[^2] | > **最佳实践**:评审者拒绝时应明确标注原因(例如:`/reject 缺少单元测试覆盖率`),提交者修复后通过 `@mention` 通知评审人重新审查 [^1]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值