分支保护必须按角色、环境、流程对齐配置，否则易失效；github main分支最小可用保护需勾选include administrators、require status checks（并指定ci任务）、require conversation resolution，且关闭force push权限。
直接上结论：分支保护不是“开了就安全”，而是必须按角色、环境、流程三者对齐来配，否则容易出现审查形同虚设、CI被绕过、或连自己都推不上去的尴尬局面。
GitHub 上怎么配 main 分支的最小可用保护？
这是团队起步时最常踩的第一个坑：只勾了 Require pull request reviews before merging，但没关掉 Include administrators，结果管理员仍能绕过审查直接合并。
- 必须开启
Require status checks to pass before merging，并至少填一个 CI 的 context（比如ci/build或test/unit），否则 PR 合并按钮永远是灰色的 -
Require conversation resolution before merging建议打开，避免 Reviewer 留了评论但没人处理就合进去了 - 如果用的是 GitHub Actions，确保 workflow 文件里用了
on: pull_request而不是on: push，否则状态检查不会触发 - 别漏掉
Restrict who can push to matching branches—— 不勾它，任何人都能git push --force覆盖历史
GitLab 中 protected branches 的权限陷阱
GitLab 的保护逻辑和 GitHub 不同：它把“推送”和“合并”权限分开控制，而且默认允许 Maintainer 直接推送。很多团队配置完发现开发人员还是能推到 main，其实是没注意到 push_access_levels 和 merge_access_levels 是两个独立开关。
- 生产分支建议设为：
push_access_levels = [NO_ACCESS]，merge_access_levels = [DEVELOPER]（或更低） - 如果团队用 MR 模板，记得在
.gitlab-ci.yml里加only: [merge_requests]，否则 pipeline 可能在 feature 分支上误跑全量测试 - GitLab 16.0+ 支持基于正则的分支匹配（如
release/v[0-9]+\.[0-9]+\.[0-9]+），比通配符release/*更精准，避免误伤release-notes
Gitee / Gitea / GitBucket 怎么做等效配置？
这些平台没有 GitHub 那么多细粒度选项，但核心逻辑一致：先锁写入，再控合并路径。Gitee 尤其要注意它的“保护规则”入口藏得深——得先进入「仓库设置 → 代码管理 → 分支保护」，而不是「管理 → 分支」。
- Gitea 1.21+ 支持
require_signed_commits，适合金融类项目；但开启后所有 commit 必须用 GPG 签名，否则 push 失败，错误信息是refusing to allow unsigned commits - GitBucket 4.44.0 开始支持 API 级别访问控制，比如限制只有
ci-bot用户能向staging推送构建产物，普通开发者完全不可见该分支 - 所有平台共通的一点：分支保护规则只对新提交生效，旧的直接推送记录不会被追溯清理，所以配置完要立刻通知全员停用
git push origin main这类操作
真正难的不是点几下开关，而是让分支保护和你们每天的实际工作流咬合上——比如 QA 团队要不要有 merge 权限？紧急 hotfix 是走 bypass 还是开临时白名单？这些决策点一旦模糊，规则就会变成摆设。
