Git分支权限管控的核心作用是切断人为高危操作路径，防止main分支因强制推送、未测试提交或历史混乱而损坏；它通过pre-receive钩子拦截非法操作，强制PR流程、双人审查、状态检查等规则，将人工判断转化为可审计的自动化约束。
Git分支权限管控不是“加一层锁”这么简单，它直接切断了多数人为引入的高危操作路径。没有它，main 分支可能在一次 git push --force 后丢失三天的提交历史，也可能被未测试的 hotfix 直接覆盖线上配置。
为什么 main 分支被推爆，往往不是黑客干的
真实故障里，90% 以上的 main 分支损坏来自内部误操作：新成员本地没拉最新代码就强制推送、CI 失败后手动跳过检查、PR 合并前没 rebase 导致历史混乱。分支权限管控不靠信任人，而是用规则堵住这些常见出口。
-
protected branch规则生效后，普通Developer角色对main执行git push会直接返回remote: GitLab: You are not allowed to push code to protected branches. - 即使有写权限，
force push和delete branch也会被 pre-receive hook 拦截，错误信息明确指向保护策略而非网络或认证问题 - 管理员绕过默认开启（GitHub/GitLab 默认允许），但一旦勾选
include administrators，连 Owner 推送也必须走 PR 流程
required_pull_request_reviews 不只是“多点一个 Approve”
它把“谁说了算”从个人判断变成可审计的动作。比如设置 required_approving_review_count: 2 并绑定 CODEOWNERS，意味着修改 /src/payment/ 下的文件，必须由支付模块负责人 + 架构师两人分别点击 Approve，且系统自动记录时间、IP、用户角色。
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 审查者不能是 PR 创建者（默认强制），避免自产自销
- 如果启用
dismiss stale pull request approvals when new commits are pushed，只要作者再提交一次，之前所有 approve 就失效，防止“审了但没审新改的代码” - GitLab 中还可配置
Require approval from specific users or groups，比 GitHub 的 teams 更细——能精确到 LDAP 组或外部 SSO 群组
状态检查（required_status_checks）卡在合并前，不是 CI 成功后
很多人以为 CI 跑完就算过关，其实关键在“是否作为合并前置条件”。GitHub/GitLab 都要求你显式勾选某几个 status context（如 ci/test, lint/check），只有它们全部显示 success，Merge 按钮才亮起。哪怕 CI 脚本里写了 exit 0，只要没向 Git 平台回传对应 context，就卡死。
- 名称必须完全匹配：CI 工具上报的是
build，但规则里填了ci/build，就会一直灰着 - GitHub Actions 默认 context 是
ci/test，但自建 Jenkins 可能是jenkins/pr-123，得看实际 webhook payload - GitLab 的
Allow merge when pipeline succeeds是开关，但真正起效依赖 pipeline 中rules是否覆盖了 merge request 事件
最易被忽略的一点：分支保护只管“进”，不管“出”。它防不住开发者从 main 拉出一个恶意分支，偷偷塞进后门再等几个月后合入。真正的安全闭环，需要配合仓库级权限（如禁止 fork）、提交签名（gpg.signingkey）、以及定期扫描分支图谱——保护分支是第一道门，不是最后一道墙。
