Gitlab上手指南（二）｜大多数企业为什么会使用Gitlab，Gitlab工作流是什么样的？

语言: CN / TW / HK
时间 2023-03-11 23:15:31

是什么

官方话术：

GitLab是由GitLabInc.开发，使用MIT许可证的基于网络的Git仓库管理工具，且具有wiki和issue跟踪功能。使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

GitLab由乌克兰程序员DmitriyZaporozhets和ValerySizov开发，它使用Ruby语言写成。后来，一些部分用Go语言重写。截止2018年5月，该公司约有290名团队成员，以及2000多名开源贡献者。GitLab被IBM，Sony，JülichResearchCenter，NASA，Alibaba，Invincea，O’ReillyMedia，Leibniz-Rechenzentrum(LRZ)，CERN，SpaceX等组织使用。

GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片段收集功能可以轻松实现代码复用。

为什么

为什么企业都是用gitlab，而不是github和gitee等呢？

当一个项目版本多了，开发人员多了，单纯的git管理还是很多问题，一方面是开发人员权限过大，二是运维人员不太了解我们开发上面的流程，于是想着用更好的工具来管理项目。于是想到gitlab。

CI/CD

这里的CI/CD其实指的是持续集成（CI）和持续交付、持续部署（CD），CI就是软件工程师每天频繁地将更新代码的副本传递到共享位置的过程。所有的开发工作都在预定的时间或事件中进行集成，然后自动测试和构建工作。通过CI，开发过程中出现的错误能被及时发现，这样不仅加速了整个开发周期，而且使软件工程师的工作效率更高。而CD 表示持续交付（CD）是创建高质量应用程序的第二个难题。CD是一门软件开发学科，利用技术和工具快速地交付生产阶段的代码。由于大部分交付周期都是自动化的，所以这些交付能够快速地完成。

后文我们会详细介绍CI/CD的工作流程

权限控制和协同

在一个 GitLab 项目上一起工作的最简单方法就是赋予协作者对 git 版本库的直接 push 权限。 你可以通过项目设定的 “Members（成员）” 部分向一个项目添加写作者，并且将这个新的协作者与一个访问级别关联（。 通过赋予一个协作者 “Developer（开发者）” 或者更高的访问级别，这个用户就可以毫无约束地直接向版本库或者向分支进行提交。

另外一个让合作更解耦的方法就是使用合并请求。 它的优点在于让任何能够看到这个项目的协作者在被管控的情况下对这个项目作出贡献。 可以直接访问的协作者能够简单的创建一个分支，向这个分支进行提交，也可以开启一个向 master 或者其他任何一个分支的合并请求。 对版本库没有推送权限的协作者则可以 “fork” 这个版本库，向 那个 副本进行提交，然后从那个副本开启一个到主项目的合并请求。 这个模型使得项目拥有者完全控制着向版本库的提交，以及什么时候允许加入陌生协作者的贡献。（这有点类似 github，但目前github私有库收费）

在 GitLab 中合并请求和问题是一个长久讨论的主要部分。 每一个合并请求都允许在提出改变的行进行讨论（它支持一个轻量级的代码审查），也允许对一个总体性话题进行讨论。 两者都可以被分配给用户，或者组织到 milestones（里程碑） 界面。

这个部分主要聚焦于在 GitLab 中与 Git 相关的特性，但是 GitLab 作为一个成熟的系统，它提供了许多其他产品来帮助你协同工作，例如项目 wiki 与系统维护工具。 GitLab 的一个优点在于，服务器设置和运行以后，你将很少需要调整配置文件或通过 SSH 连接服务器；绝大多数的管理和日常使用都可以在浏览器界面中完成。

Git Flow 工作流介绍

一个企业当中项目，一般来说，是几个人同时进行开发的，那么如何对git分支进行管理就成了一个重点问题。

那么这里，我们就需要介绍一下我们的git flow工作流程了。

我们先从代码的运行环境来说起。代码运⾏的环境 ⼀般来说，公司团队都会有⾄少这⼏个环境：

  • 本地开发环境： 开发⼈员⾃测的，可以是⾃⼰本地部署的静态服务器，当然也可类似是运⾏ npm server类似的环境，本地环境运⾏ 的代码可以是任何分⽀的
  • dev开发环境： 这个环境是⽤开发分⽀dev产出的代码来部署的，唯⼀的公⽤的
  • 测试&预发布环境： 这个环境是⽤开发分⽀release产出的代码来部署的，唯⼀的公⽤的
  • 线上⽣产环境： 这个环境是⽤开发分⽀master产出的代码来部署的，唯⼀的公⽤的

对应的git分支模型是这样的

对应的分支策略是这样的

  • master ：保护分⽀，对应的就是⽣产环境的分⽀
  • release：保护分⽀，所有开发完成的分⽀会申请合并到release分⽀，提供给测试⼈员测试
  • feature-*：功能分⽀，具体功能开发
  • dev/test-*：开发分⽀&脏分⽀，对应的是⼤家共⽤的开发环境，上⾯的代码会部署到⼀个公共的开发环境，供开发⼈ 员做⾃测，应付⼀些⽇常、⾮⽇常的调试
  • hotfix-*：bug紧急修复分⽀，可以直接合并到master，（假如release合并了⼏个feature分⽀，正在测试的情况 下，发现需要紧急修复的buf，紧急修复测试完毕后，可以直接合并到master，如果合并到release，在由 release合并到master，那些正在测试的功能或者还不准备上线的功能就会跟着直接上线了）

工作流程介绍

  1. 接到需求⽂档，做评审后分配个每个⼈或⼩组的功能开发，相关⼈员从master 检出功能分⽀
  2. 开发的时候除了会在本地测试，有需要还会合并到dev分⽀，在公共的开发环境去⾃⼰做测试
  3. 因为在开发功能的期间，可能有hotfix完成合并到master，合并代码的时候习惯merge⼀下master，防⽌冲突 等
  4. ⾃测完成之后，申请合并到release，合并成功后部署到测试环境后通知测试⼈员做测试
  5. 测试通过后，release申请合并到master，准备上线
  6. 如果测试不通过，在功能分⽀修改后重新merge
  7. 上线成功稳定后删除对应的功能分⽀，dev 合并最新的master分⽀
「」
「」