Gitlab 角色与项目角色对应关系

最新推荐文章于 2024-09-14 11:23:20 发布

CarloPan

最新推荐文章于 2024-09-14 11:23:20 发布

阅读量1.6k

点赞数

分类专栏：版本管理

本文链接：https://blog.csdn.net/CarloPan/article/details/103863299

版权

版本管理专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文详细解析了Gitlab中的各种角色，包括Owner、Master、Developer、Reporter和Guest，以及这些角色对应的项目权限，如创建仓库、管理分支、检查分支规范、成员管理和系统维护等。此外，还对比了Git管理员与开发主管的具体职责。

摘要由CSDN通过智能技术生成

Gitlab 角色与项目角色对应关系

Gitlab 角色	项目角色
Owner(拥有者)	Git 管理员
Master(管理员)	开发主管
Developer(开发者)	开发人员
Reporter(报告者)	测试人员
Guest(观察者)	其他人员

Git 管理员与开发主管的职责

Git 管理员	开发主管
创建 Git 仓库	管理项目分支
检查 Git 分支规范	成员管理
维护 Gitlab 系统	管理标签

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

CarloPan

关注关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录

开发规范(一) - 分支规范

weixin_41342791的博客

01-18

1009

分支规范 master(主分支) - 稳定版 develop(开发分支) - 最新版 release(发布分支) - 发布新版本 hotfix(热修复分支)- 修复线上bug feature(特性分支) - 实现新特性 Gitlab 角色与项目角色对应关系 Owner(拥有者) Git 管理员 Master(管理员) 开发主管 Developer(开发者) 开发人员 Reporter(报告者) 测试人员 ...

GitLab使用规范

hezhanran的博客

06-10

2246

GitLab使用规范

参与评论您还未登录，请先登录后发表或查看评论

GITLAB

walle167的博客

06-10

2418

1，权限模块 GitLab的成员角色有五种

[每周一更]-(第114期)：介绍GitLab不同角色对应的权限

最新发布

hmx224_2014的专栏

09-14

1210

工作中一直使用Gitlab搭建了公司内网的代码管理工具，但是不同的用户会分配相应的权限，来管理不同用户及角色的权限信息，我们来介绍下角色的信息，方便我们管理公司内部权限分配问题，确保团队可以更好地协作，确保项目的高效开发和安全管理。GitLab 的用户角色和权限管理系统使得团队可以灵活地控制和管理项目的访问和操作权限。在 GitLab 中，角色分为项目级别和组级别，每个角色对应不同的权限级别。主要角色包括 Guest、Reporter、Developer、Maintainer 和 Owner。

GIT分支规范管理

yingyuelong的专栏

05-19

1925

• main: 主分支，也称为线上分支，主要用来版本发布。• dev：日常开发分支，该分支正常保存了开发的最新代码。• release：release 分支可以认为是 master 分支的测试版。比如说某个新增功能开发完成、线上问题紧急修复完成，那么就将 feature/hotfix 分支合并到 release 分支，到了发布日期就合并到• master 分支，进行版本发布。• feature：具体的功能开发分支。• hotfix：线上 bug 修复分支。

Gitlab 分支管理规范

所有的不期而遇都在路上 ~

03-21

2321

Gitlab Flow 项目的分支状态为： master：主分支，用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版； develop：开发分支，用于日常开发，存放最新的开发版； feat-xxx ：功能分支，一旦完成开发，它们就会被合并进develop或master，然后被删除； hotfix-xxx：正式环境补丁分支，一旦完成开发，它们就会被合并进develop或master，然后被删除； fix-xxx：开发环境补丁分支，一旦完成开发，它们就会被合并进develop

GitLab基础：使用API获取某个项目下所有成员及权限信息

知行合一止于至善

11-25

9958

这篇文章记录一下对于一个GitLab的老版本（8.11.2）使用API获取某个项目下的所有成员权限的列表的方法。

一次意外删除gitlab项目,及恢复过程

茶半香初

04-11

1万+

意外缘由: 项目上人员离职，gitlab的一些权限需要回收，但是离职人员是项目的所有者是owner权限，所以权限就收不回。结果管事的不知道是不小心还是不知道，使用root账号把项目所有者给删除了，导致3个项目都给删除了。不幸中的万幸：由于项目是处于收尾阶段，所以基本没开发，自己本地也在删除的前一天有拉取一次代码，所以代码应该是最新的，所以可以从本地恢复。但是还有一个关于发版的脚本工程代码我本地...

GitLab: 官方镜像中的PostgreSQL

知行合一止于至善

09-01

2239

从12.1版本开始，GitLab正式放弃了对MySQL的支持，转而专心一致地使用PostgreSQL。GitLab的官方镜像提供了一个ALL-in-One的包，这其中就包含PostgreSQL，这篇文章以GitLab 12.10.5的CE版本的官方镜像为例，确认一下镜像之中的PostgreSQL。

Gitlab集成jira

黄河敏捷开发

06-09

1510

在git提交或者合并分支的时候，comment字段只要带上 ISSUE-ID即可自动提交comment信息到jira上的 ISSUE-ID对应的问题注释中去。11（待办），21（处理中），31（完成）这个projectID是获取制品库ID的必填项，如果不填，构建apk时将自动退出构建。项目的第一个ISSUE，可以在JIRA上项目问题列表中获取。jira用户密码，配置为项目管理员或有项目权限的用户即可。jira用户名，配置为项目管理员或有项目权限的用户即可。为项目ID（创建项目时填写的项目唯一ID），

Gitlab与Jenkins构建CICD环境

MKC__jiaoq的博客

02-15

6335

一、概述 1、CI 持续集成持续集成：持续集成(continuous integration)是指开发者在代码开发过程中，可以频繁将代码部署集成到主干，并进行自动化测试持续交付：是指在持续集成的基础之上，将代码部署到预生产环境持续部署：在持续交付的基础之上，把部署到生产环境的过程自动化 2、持续集成流程 1、开发者将新版本 push 到 Gitlab2、Gitlab 随后触发 jenkins master 节点进行一次 build。(或者通过 web hook 定时检测)3、jenkins.

Gitlab用户角色权限Guest、Reporter、Developer、Master、Owner

hsany330的专栏

10-19

4536

Gitlab用户在组中有角色权限：Guest、Reporter、Developer、Master、Owner Gitlab权限管理。Master：可以创建项目、添加tag、保护分支、添加项目成员、编辑项目，核心RD负责人可以赋予这个权限。Owner：可以设置项目访问权限 - Visibility Level、删除项目、迁移项目、管理组成员，Developer：可以克隆代码、开发、提交、push，RD可以赋予这个权限。Reporter：可以克隆代码，不能提交，QA、PM可以赋予这个权限。

GitLab分支管理规范

能带孩子会做饭

02-27

1263

GitLab 分支管理规范只存线上的代码, 只有确定可以上线时的才合并到 `master` 上, 并且在 `master` 的基础上打 `Tag`。初次创建 `develop` 时, 需要从 `master` 分支拉取, 保持开发时代码和线上最新的代码相同。`develop` 分支是在开发时的最终分支, 具有所有当前版本需要上线的所有功能。用于开发功能的分支, 必须从最新的 `develop` 分支代码拉取。分支命名基本上是 `feature/xxxxx` (和功能相关的名字)

gitlab 将普通用户升级为管理员用户

Amy的博客

05-12

2457

使用root 用户登录gitlab服务器。查看数据库配置信息 cat /var/opt/gitlab/gitlab-rails/etc/database.yml 登录用户 su - gitlab-psql 连接库 psql -h /var/opt/gitlab/postgresql -d gitlabhq_production 查询用户 select * from users where email = ‘普通用户邮箱地址’; 更新为管理员 update users set admin=‘t’ wher.

GitLab各类型账号的权限