Gitlab使用说明

 

 

 

零、gitlab简介

 

Gitlab是一个成熟的代码管理工具。为企业和组织提供内部的源代码的存储和管理功能。

 

 

 

 

一、gitlab角色总览

 

gitlab中的角色分管理员和使用者，管理员即administrator（root）用户，使用者分创建者（owner）、维护者（maintainer）、开发者（developer）、reporter（不知道怎么翻译才好）、访客（guest）。

 

下表列出了所有使用者所拥有的权限，常规开发中，我们一般仅使用owner、maintainer、developer这三个角色。

权限	Guest	Reporter	Developer	Maintainer	Owner
Create new issues 创建议题	*	*	*	*	*
Leave comments  在线留言	*	*	*	*	*
Pull the project code  拉取代码		*	*	*	*
Download a project   下载项目zpi包		*	*	*	*
Create code snippets  创建代码片段		*	*	*	*
Create new merge requests 提交合并请求			*	*	*
Push changes to nonprotected branches 向未受保护的分支推送代码			*	*	*
Remove nonprotected branches  删除未受保护的分支			*	*	*
Add tags   添加标签			*	*	*
Write a wiki    写说明			*	*	*
Manage the issue tracker 管理议题			*	*	*
Add new team members    添加成员				*	*
Push changes to protected branches  向受保护的分支推送代码				*	*
Manage the branch protection  管理受保护的分支				*	*
Manage Git tags  管理标签				*	*
Edit the project   编辑项目信息				*	*
Add deploy keys to the project   添加项目部署密钥				*	*
Configure the project hooks   配置项目的钩子调用				*	*

 

gitlab名词解释：

• 项目：项目即代码仓库，一般一个代码仓库对应一个代码工程
• 受保护分支：“受保护”是相对而言，一般来说，受保护主要体现在以下方面：开发者角色是否可以push代码；开发者角色是否可以对已创建的合并请求操作合并

 

 

二、代码仓库管理思路

 

总体思路：

• 项目经理承担owner角色，负责创建代码仓库
• 项目经理酌情指派一名核心开发人员为maintainer角色，负责此代码仓库的日常管理如添加开发者、审核合并请求。目的是为了分担项目经理在代码管理方面的工作，建议不要肆意分配maintainer角色，因为该角色权力太大
• 项目开发人员分配developer角色，负责代码开发和提交合并请求
• 仅参与此项目的人员才分配角色，不参与此项目的人员无权查看

 

新项目代码仓库管理流程：

 

• 项目经理创建代码仓库 

• 项目经理（或maintanier）添加开发人员
• 项目经理（或maintanier）基于master分支创建dev分支
• 开发人员基于dev分支创建feature分支
• 开发人员克隆gitlab中的仓库到本地
• 开发人员提交代码到本地仓库
• 开发人员push本地仓库到远程（gitlab）仓库 
• 开发人员提交合并请求源分支为feature，目标分支为dev 
• 项目经理（或maintanier）审核合并请求将多个feature分支代码合并到dev分支 
• 项目经理（或maintanier）基于dev分支创建test分支
• 测试人员在test分支上做功能测试
• 开发人员基于test分支创建fixbug分支修改bug 
• 开发人员提交合并请求，源分支为fixbug，目标分支为test 
• 项目测试完毕 
• 项目经理（或maintanier）创建prod分支做预发布测试
• 发布完毕，创建tag
• 项目经理（或maintanier）将prod分支合并到master分支

 

 

老项目迭代开发代码仓库管理流程：

• 项目经理（或maintanier）基于已有代码仓库创建dev分支
• 项目经理（或maintanier）添加开发人员
• 开发人员基于dev分支创建feature分支
• 开发人员克隆gitlab中的仓库到本地
• 开发人员提交代码到本地仓库
• 开发人员push本地仓库到远程（gitlab）仓库 
• 开发人员提交合并请求，源分支为feature，目标分支为dev 
• 项目经理（或maintanier）审核合并请求将多个feature分支代码合并到dev分支 
• 项目经理（或maintanier）基于dev分支创建test分支
• 测试人员在test分支上做功能测试
• 开发人员基于test分支创建fixbug分支修改bug 
• 开发人员提交合并请求，源分支为fixbug，目标分支为test 
• 项目测试完毕
• 项目经理（或maintanier）创建prod分支做预发布测试
• 发布完毕，创建tag
• 项目经理（或maintanier）将prod分支合并到master分支

 

三、分支管理思路

 

分支种类：

• master：主分支，是受保护分支，不可直接push
• dev：开发分支，基本上可以跟着迭代走，每一个迭代一个dev分支，dev分支从master分支创建。是受保护分支，不可直接push
• feature：特性分支，也即功能开发分支，一般情况下feature和dev分支是如影随形关系。feature从dev分支创建，开发人员在feature分支开发代码，开发完毕提交MergeRequest，拥有合并权限（即maintainer角色）的开发人员（开发组长、项目经理等）完成代码审核（非必须）并合并到dev分支，运维人员在jenkins中构建dev分支，这样开发的功能就部署到开发环境了。
• test（或者叫release）：测试分支，用于部署到测试环境的分支，从dev分支创建，是受保护分支，不可直接push。test分支代码测试完毕，合并到master。
• fixbug：bug修复分支，用于修改测试过程中测试人员提交的bug，从test分支创建，是修改bug的开发人员工作分支。
• hotfix：//todo
• prod：//todo

 

 

 

　　基于实际开发场景，feature分支和fixbug分支为可选项，例如如果本次迭代功能少，周期短，参与人员不超过3个人，完全可以都在dev分支上面开发，在test分支上面改bug，引入feature分支和fixbug分支反而产生了负担。

 

 

分支取名：

• 分支名包含三部分：分支类型，8位日期，分支描述
• 8位日期如20211024
• 分支描述用简洁小写英文单词或者汉语拼英首字母小写，中间用横线隔开

 

例如：feature-20211024-car-management