分支保护只能在远端平台（gitlab/github/gitee）配置，git 本身不支持 --lock、--protected 等虚构参数，本地命令无法真正阻止推送，所有生效逻辑均依赖远端服务拦截。
分支保护不是本地 Git 命令能改的，所有有效设置必须在远端平台（GitLab/GitHub/Gitee）完成；git branch --set-upstream-to 或 git branch --lock 这类命令根本不存在，纯属误导。
Git 本身不提供分支保护机制
Git 是分布式版本控制系统，它没有“服务器端权限”概念。所谓“保护分支”，全是托管平台（GitLab、GitHub、Gitee 等）在接收 git push 请求时做的拦截和校验。本地执行任何 git 命令都无法真正阻止推送——哪怕你写了个 pre-push hook，删掉它就能绕过。
- 所有真实生效的保护逻辑都在远端服务：比如 GitLab 的
protected_branches表、GitHub 的 Branch Protection Rules API -
git branch命令只管理本地引用，不触碰权限策略 - 网上流传的
--lock、--protected等参数是虚构的，Git 官方文档中从未定义
GitLab 中修改已存在的保护分支规则
进入项目 → Settings → Repository → Protected Branches，找到目标分支（如 main），点击右侧铅笔图标编辑。关键点：
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
-
Allowed to push必须设为0（即No one），否则开发者仍可直接git push origin main -
Allowed to merge推荐设为40（Maintainer），避免 Developer 账号也能合并 MR - 新规则不会自动覆盖旧规则：若已有同名分支被保护，需先删除旧规则再新建，或直接编辑现有条目
- 通配符规则（如
release/*）优先级低于精确匹配，且只对新创建的分支即时生效
GitHub 上更新 main 分支保护规则容易漏掉的三项
进 Settings → Branches → 找到 main 对应的 rule，点 Edit。常被忽略但关键的配置：
- 必须勾选
Include administrators：否则 Org Admin 或 Repo Owner 可以绕过所有规则直接 push -
Dismiss stale pull request approvals when new commits are pushed不开的话，旧审批长期有效，新人提交后仍能合入 -
Require status checks to pass before merging里要手动勾选具体 job 名（如test、build），只勾选该大框但不选子项 = 无效
Gitee 评审模式 vs 标准模式的实际影响
Gitee 的“评审模式”不是语法糖，它改变了推送行为本身：
- 标准模式下：
git push origin main直接失败，返回remote: You are not allowed to push code to protected branch - 评审模式下：同样命令会成功，但远端自动创建或更新一个 PR，源分支名类似
auto-12345-main-1625833887 - 评审模式不等价于“宽松保护”——它依然禁止直接合入，只是把“拒绝”变成了“转交 PR 流程”
- 该模式对 CI 集成有隐性要求：CI 脚本需识别
GITEE_PR_ID环境变量，而非仅依赖CI_COMMIT_REF_NAME
真正起作用的永远是远端服务返回的 HTTP 状态码或 SSH 拒绝消息，不是你本地 .git/config 里写了什么。别在本地折腾 hook 当防线，它连提醒都未必可靠——人总能 git push --no-verify。
