必需状态检查是什么
分支保护可以要求指定 CI 检查全部通过才允许合并（GitHub 的 Required status checks、GitLab 的 Pipelines must succeed）。再加上「分支需最新」（Require branches to be up to date）后，源分支落后目标分支时要先更新再合并，避免「基于旧主干验证过就直接合并」的脏合并。两者结合后，进主干的代码都在与最新主干组合验证过。
基本信息
| GitHub | 分支保护 Required status checks；strict 即「需最新」 |
|---|---|
| GitLab | 合并前流水线必须成功等合并设置 |
| 联动机制 | 合并队列或合并列车可部分替代手工「保持最新」 |
| 检查选择 | 只把关键任务（构建、核心测试）设为必需 |
| 查看状态 | gh pr checks 或平台页面的检查面板 |
典型使用场景
- 主干质量守门：单测、构建、类型检查全绿才允许合并。
- 合规审计：要求指定流水线留有通过记录。
- 保护发布分支：发布分支只收通过完整流水线的合并。
- 防止脏合并：strict 模式保证与最新目标分支组合验证。
- 高风险目录：对核心路径要求额外检查项。
- 机器人提交：自动同步类 PR 同样纳入检查约束。
常用命令
常用命令
gh pr checks 128 # 查看当前 PR 的检查状态
gh pr status # 总览自己的 PR
gh pr merge 128 # 检查未过时平台会拒绝合并
# 分支落后目标分支时先更新（团队统一 merge 或 rebase 口径）
git fetch origin && git merge origin/main概念对照
| 概念 | 含义 | 平台 |
|---|---|---|
| Required checks | 必须通过的检查集合 | GitHub |
| 需最新（strict） | 要求分支不落后目标 | 两个平台均有类似设置 |
| Pipelines must succeed | 流水线必须成功 | GitLab |
| 合并队列/列车 | 队列化按序验证合入 | 进阶组件 |
检查项应保持精简且稳定：每个必需项都引入一轮等待，过多检查显著拖慢合入；改工作流任务名时要同步修改保护设置，否则规则会静默失效。