git远程分支保护由托管平台（github/gitlab/gitee）服务端实现，非git本体功能；推送被拒是平台hook拦截所致，常见于分支保护规则触发或本地历史落后于远程。
Git远程分支没有原生权限系统，所有“推不上去”“被拒绝”“必须走PR”的行为，都是托管平台（GitHub/GitLab/Gitee）在服务端拦截的，不是git命令本身限制的。
为什么git push会被拒绝：看清是平台拦的，不是Git拦的
执行git push origin main报错，比如remote: GitLab: You are not allowed to force push code to a protected branch，这不是git在本地做了什么判断，而是远端服务器（如GitLab的pre-receive hook）收到推送后主动中止了操作。
常见误判点：
- 看到
! [rejected] main -> main (non-fast-forward)，第一反应不是“权限不够”，而是先git pull origin main——大概率只是本地落后，跟保护规则无关 - 以为
git config --global branch.main.mergeOptions能控制远程推送权限——它只影响git merge本地行为，对push零作用 - 搜到
git branch --protect这类命令就试——官方git压根没这个子命令，纯属文档误导
分支保护规则在哪配：平台UI或配置文件，不是本地.git
所谓“保护分支”，真实载体是托管平台的配置：
- GitHub：进 Settings → Branches → Branch protection rules，可设
Require pull request reviews、Require status checks、Include administrators - GitLab：Settings → Repository → Protected branches，分开控制
Allowed to merge和Allowed to push，Maintainer可推但Developer不能 - Gitee：设置 → 仓库保护 → 启用「评审模式」，此时
git push origin main不会报错，而是自动创建/更新PR - GitHub还支持
.github/branch-protection.yml声明式配置，但需仓库启用branch_protection_rules功能且有admin权限
想绕过保护？别试了，也绕不过
强制推送（git push -f）在主流平台默认被禁用，且无法通过客户端配置解除：
- GitHub上即使你是Owner，开启
enforce_admins: true后，-f也会被拒 - GitLab里
Allowed to push若设为None，连Maintainer都推不了，-f照样失败 - 本地改
.git/config加deny或acl字段？Git根本不读这些——那是Gitolite或自建Git服务器才认的规则 - 有人改
pre-push钩子想本地拦截？那只能防自己，对远端毫无意义；真正起效的是服务端pre-receive或update钩子，你没权限碰
团队该怎么做：把流程意识刻进操作习惯
权限不是靠“锁死”实现的，而是靠“默认走对路径”降低出错概率：
- 主分支（
main/master）一律设为保护分支，禁止直接push，只允许通过PR合并 - 开发人员本地不建
main分支，而是用git checkout -b feat/login origin/dev从dev拉新分支 - CI状态卡在
pending导致PR无法合？检查.github/workflows/ci.yml里on:是否漏了pull_request，或required_status_checks.contexts写的job名和实际CI job名不一致 - 新人第一次
git push失败，别急着找权限，先git branch -vv看追踪关系是否建立，再git status确认当前分支干净
最易被忽略的一点：分支保护生效的前提，是你推送的目标引用（refs/heads/main）确实匹配平台配置的规则名称。比如你在GitHub设了main保护，却往master推——那根本不会触发任何拦截，等于裸奔。
