Git_02_GitLab协作与CI_CD

【GitLab】协作与 CI/CD：Merge Request、分支保护与流水线

🔑 关键词：GitLab、Merge Request、分支保护、CI/CD、.gitlab-ci.yml、Webhook

一、什么是 GitLab？

GitLab 是一个基于 Git 的代码托管与 DevOps 平台，提供代码仓库、Merge Request、CI/CD、Issue 管理、容器镜像仓库等一站式功能。

📌 一句话理解：GitLab = GitHub + Jenkins + Jira，一个平台搞定代码托管、协作和自动化。

1.1 GitLab vs GitHub

对比	GitLab	GitHub
CI/CD	内置，功能强大	GitHub Actions（后加入）
私有化部署	✅ 支持自建	❌ 仅 SaaS（企业版除外）
权限管理	更细粒度	相对简单
免费私有仓库	✅	✅
国内访问	自建无问题	偶尔不稳定

二、项目与成员管理

2.1 创建项目

GitLab 中项目分为三种可见性：

Private：仅成员可见
Internal：登录用户可见
Public：所有人可见

2.2 成员角色

角色	权限
Guest	查看 Issue、发表评论
Reporter	查看代码、查看 CI/CD
Developer	创建分支、推送代码、创建 MR
Maintainer	合并 MR、管理分支保护、管理成员
Owner	项目所有权限，包括删除项目

💡 实际团队：普通开发者通常是 Developer，Tech Lead 是 Maintainer。

三、Merge Request（合并请求）

3.1 MR 工作流

复制代码

1. 从 develop 创建 feature 分支
2. 开发完成后 push 到远程
3. 在 GitLab 创建 Merge Request（feature → develop）
4. 指定 Reviewer 进行代码审查
5. 审查通过 → 合并

3.2 创建 MR 的关键要素

要素	说明
Source Branch	你的开发分支
Target Branch	合并目标分支
Assignee	负责人
Reviewer	代码审查者
Milestone	关联的里程碑/版本
Labels	标签（bug/feature/docs）
Description	描述改动内容

3.3 MR 描述模板

markdown 复制代码

## 改动说明
- 新增动物列表分页查询接口
- 修复动物年龄计算错误

## 关联 Issue
Closes #123

## 测试情况
- [x] 单元测试通过
- [x] 本地接口测试通过

## 截图
（如有 UI 改动）

3.4 MR 合并方式

方式	说明
Merge Commit	创建合并提交，保留完整分支历史
Squash and Merge	将分支所有提交压缩为一个
Fast-Forward Merge	线性合并，不产生合并提交

💡 推荐：功能分支用 Squash and Merge，保持主分支历史干净。

四、分支保护

4.1 为什么要保护分支？

防止开发者直接 push 到 main/develop 等关键分支，强制通过 MR 流程。

4.2 配置分支保护

复制代码

Settings → Repository → Protected Branches

Protected branch: main
Allowed to merge: Maintainers
Allowed to push: No one（禁止直接推送）

4.3 常见保护策略

分支	保护规则
`main`	禁止直接 push，只能通过 MR 合并，需要 Maintainer 审批
`develop`	禁止直接 push，Developer 可以通过 MR 合并
`release/*`	仅 Maintainer 可以创建和合并

4.4 审批规则

GitLab 支持设置 MR 审批人数：

至少 1 人 Approve 才能合并
可以指定特定人员必须审批
Code Owner（代码所有者）审批

五、Issue 与 Milestone

5.1 Issue 管理

markdown 复制代码

# Bug 报告模板
## 问题描述
分页查询第2页数据重复

## 复现步骤
1. 访问 /api/animals?page=2&size=10
2. 返回数据中包含第1页的记录

## 期望结果
每页数据不重复

## 环境
- JDK 21
- MySQL 8.0
- Spring Boot 3.2

5.2 Milestone（里程碑）

用于规划版本发布，关联多个 Issue 和 MR：

复制代码

Milestone: v1.2.0
Due Date: 2026-10-15
Issues: #101, #102, #105, #108

六、CI/CD 基础

6.1 核心概念

概念	说明
Pipeline	流水线，一次完整的 CI/CD 流程
Stage	阶段，如 build → test → deploy
Job	任务，每个阶段中的具体执行单元
Runner	执行器，实际运行 Job 的机器
.gitlab-ci.yml	流水线配置文件，放在仓库根目录

6.2 执行流程

复制代码

代码 push / MR 触发
    ↓
Pipeline 创建
    ↓
Stage: build   → Job: compile, Job: package
Stage: test    → Job: unit-test, Job: integration-test
Stage: deploy  → Job: deploy-staging, Job: deploy-production
    ↓
Pipeline 完成 ✅ / 失败 ❌

6.3 .gitlab-ci.yml 示例

yaml 复制代码

# 定义阶段
stages:
  - build
  - test
  - deploy

# 构建阶段
build:
  stage: build
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
    expire_in: 1 hour

# 测试阶段
unit-test:
  stage: test
  script:
    - mvn test
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml

# 部署到测试环境
deploy-staging:
  stage: deploy
  script:
    - echo "部署到测试环境"
    - scp target/*.jar deploy@staging-server:/app/
  only:
    - develop       # 只在 develop 分支触发
  environment:
    name: staging

# 部署到生产环境
deploy-production:
  stage: deploy
  script:
    - echo "部署到生产环境"
  only:
    - main          # 只在 main 分支触发
  when: manual      # 手动触发
  environment:
    name: production

6.4 关键配置说明

关键字	说明
`stages`	定义阶段顺序
`stage`	指定 Job 属于哪个阶段
`script`	执行的命令
`only / rules`	触发条件（分支/标签/MR）
`when`	执行时机（on_success/manual/always）
`artifacts`	传递产物给后续阶段
`environment`	部署环境
`cache`	缓存依赖（如 .m2 目录）

6.5 缓存配置

yaml 复制代码

# 缓存 Maven 依赖，加速构建
cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - .m2/repository

七、Webhook

7.1 什么是 Webhook？

GitLab 在特定事件（push/MR/Tag）发生时，向你配置的 URL 发送 HTTP POST 请求。

7.2 使用场景

场景	说明
自动部署	push 到 main 后触发 Jenkins/自建部署脚本
通知	推送/合并时发送钉钉/企业微信通知
自动测试	MR 创建后触发自动化测试
同步	代码变更同步到其他系统

7.3 配置

复制代码

Settings → Webhooks
URL: https://your-server.com/webhook/gitlab
Trigger: Push events, Merge request events
Secret Token: your-secret-token

八、面试高频问题

Q1：Merge Request 的作用？

答：MR 是代码审查（Code Review）的核心工具。开发者完成功能后创建 MR，指定 Reviewer 审查代码，审查通过后才能合并到目标分支。它可以保证代码质量、促进知识共享、防止低质量代码进入主分支。

Q2：CI/CD 的 Pipeline 包含哪些？

答：Pipeline 是 CI/CD 的完整执行流程，由多个 Stage 组成，每个 Stage 包含若干 Job。典型流程：build（编译打包）→ test（单元测试/集成测试）→ deploy（部署到测试/生产环境）。通过 .gitlab-ci.yml 定义。

Q3：为什么要保护 main 分支？

答：防止开发者直接 push 代码到主分支，绕过代码审查流程。通过分支保护，强制所有改动必须通过 MR 合并，确保每次变更都经过 Review 和 CI 验证，保障主分支的代码质量和稳定性。

九、总结

功能	核心要点
成员管理	Guest → Developer → Maintainer → Owner
Merge Request	代码审查核心工具，支持审批规则
分支保护	禁止直接 push，强制 MR 流程
Issue/Milestone	需求跟踪与版本规划
CI/CD	.gitlab-ci.yml 定义 Pipeline（build→test→deploy）
Webhook	事件触发外部系统联动

📝 下一篇预告：《GitFlow 分支工作流》，详解五种分支模型的完整协作流程。