零、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