保护分支是什么
GitLab 的保护分支决定谁能推送、谁可以合并，以及是否允许强推。它是约束主干合入路径的基础设施：只有和审批规则、必需流水线组合起来，才能同时管住「谁能写进去」和「写进去要经过什么」。哪些分支需要保护要按风险面来定，而不是只锁默认分支。
基本信息
| 配置路径 | Settings → Repository → Protected branches |
|---|---|
| 控制点 | 允许推送、允许合并、是否允许强推 |
| 联动机制 | 合并请求审批规则与必需的流水线 |
| 基础组合 | 主干禁止强推 + 必须走合并请求 |
典型使用场景
- 默认分支只允许维护者推送，日常改动一律走合并请求
- 发布分支同样纳入保护，避免发布线被直接改写
- 关闭强推，保证主干历史始终可追溯
- 配合审批规则，规定改动必须经过几人批准
- 为紧急修复预留例外通道，并写明事后审计方式
- 新成员加入时用保护规则限制误操作的影响范围
常见配置思路
常见配置思路
# Settings → Repository → Protected branches
# 默认分支：允许推送仅维护者，合并需审批，强推关闭
# 发布分支：同样禁止强推，允许合并的角色单独配置
# 例外通道：紧急修复直推需两人确认，事后补记录控制点读法
| 控制点 | 含义 | 常见取值 |
|---|---|---|
| 允许推送 | 谁可以直接写入该分支 | 仅维护者 / 无人 |
| 允许合并 | 谁能把合并请求合入 | 维护者或指定角色 |
| 允许强推 | 是否可以改写该分支历史 | 关闭 |
| 必需流水线 | 合并前是否要求流水线通过 | 开启 |
主干禁止强推加必须走合并请求，是保护历史的常见基础配置。先把它做上，再按团队情况增加审批与流水线要求。
例外通道要写清适用条件、审批人和事后补记录的方式，否则例外用着用着就会变成常态。