spring suite gitlab使用手册

一、gitlab介绍

GitLab是一个功能丰富的开源代码管理平台，基于Git进行版本控制，并提供了一系列用于团队协作、项目管理、持续集成/持续部署（CI/CD）等工具。以下是关于GitLab的详细介绍：

基础信息 ：
- GitLab最初由Dmitriy Zaporozhets和Valery Sizov于2011年创建，是一个用于仓库管理系统的开源项目。
- 它使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。
- GitLab使用Ruby on Rails构建，后来部分用Go语言重写。
功能特点 ：
- 版本控制：GitLab允许多名开发人员在统一项目中进行并行开发，通过Git进行代码的合并、分支、提交和版本回退。
- 协同开发：GitLab提供了代码审查、问题跟踪、wiki等功能，支持团队之间的协作开发。
- 持续集成/持续部署（CI/CD）：GitLab内置了CI/CD工具，可以自动进行代码测试、构建和部署。
- 项目管理：提供了全面的项目管理功能，如里程碑、任务分配、进度跟踪等。
- 安全性管理：支持用户权限分配、角色管理、双因素身份验证、代码扫描和安全漏洞报告等功能。
版本与部署 ：
- GitLab最初是完全免费的开源软件，按照MIT许可证分发。
- 2013年7月，GitLab被拆分为GitLab CE（社区版）和GitLab EE（企业版），两者都基于MIT许可分发。
- GitLab提供了自托管和云托管两种部署方式，满足不同团队的需求。
用户与贡献者 ：
- GitLab被IBM、Sony、NASA、Alibaba等众多知名组织使用。
- 截止2018年5月，GitLab公司约有290名团队成员，以及2000多名开源贡献者。
与其他平台比较 ：
- GitLab在功能和定位上更加面向企业和组织，提供了丰富的功能和高度定制化、自定义配置的能力。
- 与GitHub相比，GitLab更适合需要自托管和高度定制化的场景。
优势：
- 提供了完整的项目管理功能和自动化化构建、测试和部署工具。
- 官方提供了完整的容器部署方案，并可以与Kubernetes等容器编排平台集成。
- 提供了丰富的集成和拓展性选项，支持容器集成。

二、spring suite gitlab使用手册

team界面

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

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

gitlab名词解释：

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

分支管理思路

分支种类：

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位日期如20240524
分支描述用简洁小写英文单词或者汉语拼英首字母小写，中间用横线隔开

三、代码合并（重点内容）

步骤：

1、分支全部 pull一遍，保证当前代码为最新的代码

1、第二步切换到主分支（这里注意的是不要直接把代码合并到主分支 master，因为代码没有经过测试是有风险的，不能直接发布到生产环境）

2、通过主分支创建一个合并分支（如： master-pre）

3、提交master-pre

这是master-pre 和主分支的代码master应该是一致的

4、将分支代码合并到 master-pre

5、将master-pre发布，测试

6、master-pre代码测试没问题后再将master-pre合并到master

7、最后将master发布生产环境

代码合并完成。。