Skip to main content
☘️ Septvean's Documents
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. Documents
  2. /
  3. Operations
  4. /
  5. GitLab
  6. /
  7. GitLab 核心概念

GitLab 核心概念

内容：为什么需要 GitLab -> 核心对象 -> 底层架构 -> CI/CD 理论模型 -> 权限与治理 -> 企业级抽象

一、GitLab 是什么（本质理解）

一句话定义：

GitLab 是一个以 Git 仓库为中心，将 代码 -> 流程 -> 权限 -> 自动化 -> 部署 -> 反馈 全部打通的 一体化 DevOps 平台。

它解决的不是「存代码」，而是：

如何让代码在可控、安全、可审计的前提下，稳定、高频地流向生产环境。

二、GitLab 的核心抽象模型（非常重要）

GitLab 的所有功能，最终都围绕 5 个核心对象 运转：

Repository（代码）
│
├─ Commit（提交）
│
├─ Branch / Tag（分支 / 标签）
│
├─ Merge Request（变更入口）
│
├─ Pipeline（自动化流程）
│
└─ Environment（运行环境）

你理解了这 5 个对象，就理解了 GitLab 的 80%。

三、GitLab 的核心对象详解

1️⃣ Repository（仓库）

本质：

  • 一个 Git 仓库
  • 包含源码、历史、分支、标签

GitLab 在 Git 之上增加了：

  • 权限
  • 审计
  • CI/CD
  • 可视化管理

📌 认知重点：

  • GitLab ≠ Git
  • GitLab = Git + 管理 + 自动化

2️⃣ Commit（提交）

  • 最小变更单元
  • 是 CI/CD 的真正触发源

每一个 commit：

  • 都可能触发 Pipeline
  • 都有作者、时间、diff、SHA
  • 都可追溯、可审计

📌 关键理解：

GitLab 的自动化是 commit 驱动 的，而不是人驱动。

3️⃣ Branch / Tag（分支 / 标签）

Branch（分支）

  • 用于开发流程
  • 决定 CI 是否执行、如何执行

典型分支：

main / master
develop
feature/*
hotfix/*

Tag（标签）

  • 通常表示 一次发布
  • CI 中常用于「正式发布触发点」
rules:
  - if: '$CI_COMMIT_TAG'

📌 认知模型：

  • 分支 = 流程
  • 标签 = 版本 / 发布点

4️⃣ Merge Request（MR）

这是 GitLab 的“控制中枢”

MR 本质是：

一次受控的变更申请

它绑定了：

  • 代码 diff
  • CI Pipeline
  • Reviewer
  • 审批规则
  • 安全扫描
  • 合并策略

📌 核心原则：

没有 MR，就不应该进入主干。

5️⃣ Pipeline（流水线）

Pipeline 是 GitLab 自动化的核心执行模型。

它是：

  • 由 .gitlab-ci.yml 描述
  • 由 commit / MR / tag 触发
  • 由 Runner 执行

结构模型：

Pipeline
 ├─ Stage
 │   ├─ Job
 │   ├─ Job
 ├─ Stage
 │   ├─ Job

📌 Pipeline 本质：

将「人为流程」转化为「机器可执行流程」。

6️⃣ Job / Stage（任务 / 阶段）

  • Stage：逻辑阶段（顺序）
  • Job：具体执行单元（并行）

📌 重要规则：

  • Stage 顺序执行
  • 同 Stage Job 并行执行
  • Job 失败 -> Stage 失败 -> Pipeline 失败

7️⃣ Runner（执行器）

Runner 是 CI/CD 的“工人”。

  • GitLab：调度与管理
  • Runner：真正执行命令

Runner 本身是 无状态的执行节点。

📌 关键理解：

Runner 不“属于”项目，它只是接活干。

8️⃣ Artifacts / Cache（产物 / 缓存）

概念 本质 目的
Artifacts 构建结果 传递、下载
Cache 中间依赖 加速

📌 认知模型：

  • Artifacts 是「结果」
  • Cache 是「过程优化」

9️⃣ Environment（环境）

Environment 抽象的是：

代码运行的真实世界

如：

  • dev
  • test
  • staging
  • production

GitLab 能：

  • 记录部署历史
  • 标记当前版本
  • 支持回滚

四、GitLab CI/CD 的理论模型

GitLab CI 的底层思想是：

代码变更
  ↓
自动验证（CI）
  ↓
自动构建
  ↓
自动交付（CD）

📌 核心思想：

不相信人，只相信自动化。

五、GitLab 的权限与治理模型

1️⃣ 用户与角色模型

角色是 能力集合，不是人：

  • Guest
  • Reporter
  • Developer
  • Maintainer
  • Owner

📌 核心原则：

权限永远最小化。

2️⃣ Group / Project（组织模型） 

Group
 ├─ SubGroup
 │   ├─ Project
 │   ├─ Project

用于：

  • 权限继承
  • 资源隔离
  • CI Runner 复用

3️⃣ Protected Branch / Tag

用于：

  • 防止误操作
  • 强制 MR 流程
  • 保护生产代码

📌 生产环境必须 Protected

六、GitLab 架构基础理论（简化版） 

User
 ↓
Nginx
 ↓
GitLab Rails
 ↓
Gitaly ─ Git Repo
 ↓
PostgreSQL / Redis
 ↓
Runner（CI 执行）

📌 关键点：

  • Git 操作不在 Rails 中执行
  • Gitaly 是性能与扩展核心
  • CI 执行与 GitLab 解耦

七、GitLab 的设计哲学（高级认知）

1️⃣ Everything as Code

  • Pipeline as Code
  • Infrastructure as Code
  • Policy as Code

2️⃣ Shift Left

  • 安全前移
  • 测试前移
  • 质量前移

3️⃣ Single Source of Truth

  • Git 是唯一事实来源

八、常见认知误区（非常重要）

  • ❌ GitLab = GitHub 私有版

  • ❌ CI = 写几个脚本

  • ❌ Runner 属于项目

  • ❌ Pipeline 是顺序执行

  • ❌ Cache 和 Artifacts 是一回事

  • ✅ GitLab 是流程治理平台

  • ✅ CI 是工程化能力

  • ✅ Runner 是独立执行节点

  • ✅ Job 可并行

  • ✅ Cache ≠ Artifacts

九、总结

GitLab 的核心价值，不在于“工具”，而在于：

把软件交付这件事，从“经验驱动”，变成“规则 + 自动化驱动”。