GitLab 合并请求选项说明

本文档用通俗易懂的方式解释 GitLab Merge Request 的各种配置选项

📋 目录

🔀 合并方法 (Merge Method)

1. Merge commit（合并提交）

工作方式：每次合并都会创建一个新的合并提交

提交历史示例：

主分支: A --- B --- C ----------- G (合并提交)
                     \         /
功能分支:              D - E - F

特点：

  • ✅ 完整保留所有历史记录
  • ✅ 可以清楚看到哪些提交是从分支合并来的
  • ❌ 历史记录可能比较复杂

适用场景：

  • 大型项目需要完整历史追溯
  • 需要明确区分不同功能模块的开发历史

2. Merge commit with semi-linear history（半线性历史合并）

工作方式：要求先 rebase 到最新代码，然后创建合并提交

提交历史示例：

主分支: A --- B --- C --------------- G (合并提交)
                         \         /
功能分支:                  D' - E' - F' (已更新到最新)

特点：

  • ✅ 保持相对清晰的历史
  • ✅ 避免交叉合并造成的混乱
  • ⚠️ 有冲突时需要手动 rebase

适用场景：

  • 推荐用于团队协作
  • 多人同时开发不同功能
  • 需要保持主分支历史清晰

3. Fast-forward merge（快进合并）

工作方式：不创建合并提交，直接把分支提交接到主分支后面

提交历史示例：

主分支: A --- B --- C --- D --- E --- F (线性延伸)

特点：

  • ✅ 最简洁的提交历史
  • ✅ 没有额外的合并提交
  • ❌ 无法看出哪些是合并来的
  • ⚠️ 必须先 rebase 到最新

适用场景：

  • 个人项目或小型团队
  • 追求极简的提交历史
  • 线性开发流程

⚙️ 合并选项 (Merge Options)

1. 自动解决过时的讨论

说明：当代码被修改后，相关的评论讨论会自动标记为已解决

示例场景：

代码审查者：这里有个拼写错误 "usre" → "user"
    ↓
你修改了代码
    ↓
系统自动将讨论标记为 ✅ 已解决

推荐：✅ 开启，减少手动操作

2. 显示创建 MR 的命令行链接

说明：当你在命令行 push 代码时，会显示创建 MR 的快捷链接

示例：

$ git push origin feature-login
...
remote:
remote: To create a merge request for feature-login, visit:
remote:   https://gitlab.com/your-project/-/merge_requests/new?merge_request[source_branch]=feature-login
remote:

推荐：✅ 开启，提高工作效率

3. 默认启用"删除源分支"选项

说明：MR 合并后，自动删除功能分支

示例：

合并前：main, feature-login, feature-logout
    ↓
合并 feature-login 后
    ↓
合并后：main, feature-logout (feature-login 已删除)

推荐：✅ 开启，保持仓库整洁

注意：受保护的分支不会被删除

4. Squash commits（压缩提交）

说明：将功能分支的多个提交压缩成一个提交

示例场景：

原始提交（10个零散提交）：

- feat: 添加登录功能
- fix: 修复bug
- fix: 再修复一次
- style: 格式化代码
- docs: 补充注释
- fix: 修复拼写错误
- test: 添加测试
- fix: 修复测试
- refactor: 优化代码
- chore: 更新依赖

压缩后（1个清晰提交）：

- feat: 添加登录功能 (#123)
  包含完整的功能实现、测试和文档
四种 Squash 选项对比
选项 行为 合并按钮 推荐场景
Do not allow 禁止压缩 复选框隐藏 需要保留完整历史的项目
Allow 允许压缩 复选框显示，默认不勾选 灵活处理，由开发者决定
Encourage 鼓励压缩 复选框显示，默认勾选 ✅ 推荐 - 团队协作项目
Require 强制压缩 复选框勾选且不可更改 严格要求简洁历史的项目

推荐：Encourage - 保持主分支清晰，但允许特殊情况

✅ 合并检查 (Merge Checks)

1. Pipelines must succeed（流水线必须成功）

说明：只有当 CI/CD 流水线全部通过时，才允许合并

示例：

CI/CD 流水线：
  ❌ 单元测试失败        → 不能合并
  ❌ 代码规范检查失败    → 不能合并
  ❌ 构建失败            → 不能合并
  ✅ 所有检查通过        → 可以合并

推荐：✅ 强烈推荐开启，防止有问题的代码进入主分支

如何配置 Pipeline 检查

在项目的 .gitlab-ci.yml 文件中配置代码质量检查：

stages:
  - lint # 代码检查阶段
  - build
  - deploy

# ESLint 代码检查
eslint:
  stage: lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' # 仅在 MR 时运行
  script:
    - pnpm install
    - pnpm run lint
  allow_failure: false # 失败则阻止合并

# Prettier 格式检查
prettier:
  stage: lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  script:
    - pnpm install
    - pnpm run format:check
  allow_failure: false

效果：在创建 MR 时，会自动运行这些检查，只有全部通过才能合并

子选项：Skipped pipelines are considered successful

说明：如果流水线被跳过，也视为成功

风险：⚠️ 可能会让未经测试的代码合并进来

推荐：❌ 不建议开启

2. All discussions must be resolved（所有讨论必须解决）

说明：代码审查中的所有评论和讨论都必须解决后才能合并

示例场景：

审查者评论："这个函数的逻辑有问题，建议重构"
    ↓
情况 A：你不回复 → ❌ 无法合并
情况 B：你回复但不点"解决" → ❌ 无法合并
情况 C：你修改代码并点击"解决" → ✅ 可以合并

推荐：✅ 强烈推荐开启，确保代码审查意见被处理

💡 小白推荐配置

适合团队协作的最佳配置

🔀 合并方法:
  选择: Merge commit with semi-linear history
  理由: 保持清晰历史，适合多人协作

⚙️ 合并选项:
  ✅ 自动解决过时的讨论
  ✅ 显示创建 MR 的命令行链接
  ✅ 默认启用"删除源分支"
  ✅ Squash commits: Encourage
     理由: 鼓励压缩但保留灵活性

✅ 合并检查:
  ✅ Pipelines must succeed
     ❌ Skipped pipelines considered successful (不勾选)
  ✅ All discussions must be resolved
  理由: 保证代码质量和审查质量

📚 常见问题

Q1: Rebase 是什么？

A: 把你的提交"移动"到最新的主分支上，避免合并冲突

Q2: 什么时候需要 Squash？

A: 当你的开发过程中有很多"临时提交"、"修复拼写"等零散提交时

Q3: Merge commit 和 Fast-forward 怎么选？

A:

  • 团队协作 → Merge commit with semi-linear history
  • 个人项目 → Fast-forward merge

Q4: 强制要求所有讨论解决会不会太严格？

A: 不会。这能确保代码审查不走过场，提高代码质量

🎯 快速决策树

你的项目类型是？
│
├─ 个人项目/小团队 (< 3人)
│   └─ Fast-forward merge + Allow squash
│
├─ 中小型团队 (3-10人)
│   └─ Merge commit with semi-linear + Encourage squash
│
└─ 大型团队 (> 10人)
    └─ Merge commit with semi-linear + Require squash

所有项目都建议：
✅ Pipelines must succeed
✅ All discussions must be resolved

📦 本项目实战配置

已实现的 CI/CD Pipeline 检查

本项目已配置完整的代码质量检查流水线：

流水线阶段
stages:
  - lint # 代码质量检查（ESLint + Prettier）
  - build # 构建应用
  - docker # 构建 Docker 镜像
  - deploy # 部署到 Kubernetes

# ESLint 代码检查
eslint:
  stage: lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' # 仅在 MR 时运行
    - if: '$CI_COMMIT_REF_NAME == "dev"'
  cache:
    key:
      files:
        - pnpm-lock.yaml
    paths:
      - node_modules/
  before_script:
    - npm install -g pnpm@10 --registry=https://registry.npmmirror.com/
    - pnpm install --registry=https://registry.npmmirror.com/ --frozen-lockfile
  script:
    - echo "Running ESLint..."
    - pnpm run lint
  allow_failure: false # 检查失败则阻止合并

# Prettier 格式检查
prettier:
  stage: lint
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' # 仅在 MR 时运行
    - if: '$CI_COMMIT_REF_NAME == "dev"'
  cache:
    key:
      files:
        - pnpm-lock.yaml
    paths:
      - node_modules/
  before_script:
    - npm install -g pnpm@10 --registry=https://registry.npmmirror.com/
    - pnpm install --registry=https://registry.npmmirror.com/ --frozen-lockfile
  script:
    - echo "Running Prettier check..."
    - pnpm run format:check
  allow_failure: false # 检查失败则阻止合并
代码检查 Jobs

1. ESLint 检查

  • 触发条件：Merge Request 或主要分支（dev/test/staging/master）
  • 检查内容：代码规范、潜在错误、最佳实践
  • 失败策略：allow_failure: false - 检查失败则阻止合并

2. Prettier 检查

  • 触发条件：Merge Request 或主要分支
  • 检查内容：代码格式是否统一
  • 失败策略：allow_failure: false - 检查失败则阻止合并
本地开发命令
# 运行 ESLint 检查
pnpm run lint

# 运行 Prettier 检查（不修复）
pnpm run format:check

# 同时运行 ESLint 和 Prettier 检查
pnpm run lint:check

# 自动修复格式问题
pnpm run format
工作流程示例
开发者提交代码
    ↓
创建 Merge Request
    ↓
自动触发 Pipeline
    ├─ ESLint 检查 ──┐
    └─ Prettier 检查 ─┤
                      ↓
    ✅ 全部通过 → 可以合并
    ❌ 有失败 → 必须修复后才能合并
GitLab 项目设置建议

在 Settings > Merge requests 中配置：

合并方法: Merge commit with semi-linear history
合并选项:
  ✅ Enable "Delete source branch" option by default
  ✅ Squash commits: Encourage

合并检查:
  ✅ Pipelines must succeed
  ❌ Skipped pipelines are considered successful (不勾选)
  ✅ All discussions must be resolved

这样配置后，每次创建 MR 时都会自动进行代码质量检查，确保代码规范统一。

文档更新时间: 2026年3月2日

# gitlab # 服务器 # 前端
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

当 AI 修图师装上“万能插头“：MCP 如何改变修图工作流

avatar AI编程社区
cover

2026年8月开发者实战指南：ChatGPT Plus / Pro + Codex 如何协同完成需求分析、编码、测试、调试与代码审查

avatar AI编程社区
cover

投资一台B300，部署Claude Opus 5多久才能回本？

avatar AI编程社区