一、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发布生产环境
代码合并完成。。