什么是合并请求的自动合并
在团队协作开发中，每天都会产生大量的代码变更。为了保证主分支的稳定性，通常会通过合并请求（Merge Request）来管理代码合入。当一个功能开发完成，提交了合并请求后，如果还要手动点击“合并”，效率就会很低。
这时候，自动合并功能就派上用场了。只要满足预设条件，系统就会在检查通过后自动把代码合并进去，省时又省心。
常见的自动合并触发条件
不同的代码托管平台，比如 GitLab、GitHub 或 Gitee，支持的自动合并策略略有不同，但核心逻辑差不多。最常见的是以下几种条件：
- 所有 CI/CD 流水线通过
- 至少有两位同事批准
- 没有开启“阻止合并”的讨论
- 目标分支是 main 或 master
举个例子，你在公司做前端开发，每次提 MR 后都要等后端同事 Review。如果他们忙，你就得干等着。但如果设置了“审批通过 + CI 通过后自动合并”，你就可以继续写下一个需求，不用来回切换上下文。
如何配置 GitLab 的自动合并
GitLab 提供了“合并时关闭”和“合并后删除源分支”的选项，同时也支持真正的自动合并。你可以在 MR 页面点击“合并选项”下拉菜单，选择“当流水线成功时合并”。
如果你使用的是 GitLab CI，还可以在 .gitlab-ci.yml 中加入更精细的控制：
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: always
- when: never
stages:
- test
- deploy
unit_test:
stage: test
script: npm run test:unit
rules:
- if: $CI_MERGE_REQUEST_ID
e2e_test:
stage: test
script: npm run test:e2e
when: manual
rules:
- if: $CI_MERGE_REQUEST_ID这样配置后，只有当 MR 触发且单元测试通过，才会进入后续流程。如果所有自动检查都绿了，就可以放心开启自动合并。
GitHub 上的类似功能
GitHub 叫这个功能“Auto-merge”。你可以在 PR 页面看到一个“Enable auto-merge”的按钮。点击后可以选择“Squash and merge”或“Create a merge commit”等方式。
前提是你所在仓库开启了“Require status checks to pass before merging”和“Required approving reviews”。这些都在 Settings → Code and automation → Branches 里配置。
比如你们团队规定：PR 必须有 1 个 review 通过，CI 跑完才能合。那只要满足这些，PR 审核一结束，自动合并立刻生效，不需要再回来点一下。
什么时候不适合开自动合并
不是所有情况都适合。比如发布前的紧急修复，虽然 CI 通过了，但你可能想再看一眼 diff 确认有没有误伤。这时候手动操作更稳妥。
还有就是跨团队协作的 MR，对方可能还在讨论细节，即使代码没问题，也不该贸然合并。可以只对内部小改动开启自动合并，重大变更仍保留人工确认。
另外，如果 CI 脚本本身不稳定，偶尔出现“假阳性”，那就更不能开了。否则可能会把有问题的代码自动合进去，半夜被报警叫醒。
提升协作效率的小建议
可以把自动合并当成一种“信任机制”。当你敢打开它的时候，说明你们的测试覆盖率够高，评审流程也跑顺了。
新项目初期可以先不开，等流程稳定后再逐步启用。也可以从非主干分支开始试点，比如先在 dev 分支上尝试，运行一段时间没问题，再推广到 main 分支。
最后提醒一点：别忘了通知团队成员。有人可能不知道自动合并已经开了，还在等你手动点，结果发现代码已经悄无声息地进去了。”,"seo_title":"合并请求自动合并条件详解","seo_description":"了解如何设置合并请求的自动合并条件，提升团队开发效率，适用于 GitLab 和 GitHub 等平台的实际配置方法。","keywords":"合并请求,自动合并,合并条件,CI/CD,代码合并,GitLab,GitHub"}