【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 描述模板
## 改动说明
- 新增动物列表分页查询接口
- 修复动物年龄计算错误
## 关联 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 管理
# 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 示例
# 定义阶段
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 缓存配置
# 缓存 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 分支工作流》，详解五种分支模型的完整协作流程。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/Zhou141136/article/details/166845782
