团队协作开发时，经常遇到这种问题：小王误删了 main 分支，小李往 release 分支直接 push 了未测试代码，导致上线翻车。其实 Git 本身不带分支权限管理，但配合 Git 服务器（比如 GitLab、GitHub Enterprise、Gitee 企业版或自建 Gitee）就能实打实地给分支上锁。
GitLab 上怎么设分支保护？
以 GitLab 为例，进到项目页面 → 左侧菜单点「Settings」→「Repository」→ 滚动到底部点「Protected branches」。这里能看到当前已保护的分支，比如 main、develop 默认常被保护。
点击「Protect」按钮添加新保护规则：
• 分支名填 release/*（支持通配符，所有 release 开头的分支都生效）
• 允许合并人：选「Maintainers」或指定几个开发组长
• 允许推送人：勾选「No one」，这样普通成员连 push 都不能 push 到这个分支
• 勾选「Require approval from code owners」还能强制 PR 必须经 CODEOWNERS 文件里指定的人审批
GitHub Enterprise 怎么配？
进入仓库 → 「Settings」→ 「Branches」→ 「Add rule」：
• Branch name pattern 填 main 或 hotfix-*
• 勾选「Require pull request reviews before merging」
• 设置「Required approving reviewers」为 2 人
• 关闭「Allow force pushes」和「Allow deletions」
• 还能开启「Require status checks to pass before merging」，比如 Jenkins 构建成功、单元测试通过才允许合入
自建 Gitee 或私有 Git 服务怎么办？
如果用的是 Gitee 企业版，路径类似：项目 →「管理」→「分支保护规则」，支持按正则匹配分支、设置推/合权限等级（访客/开发者/管理员）、启用提交信息格式校验（比如必须含 JIRA 编号）。
如果是纯命令行 Git + 自建服务（如 Gitolite），就得靠配置文件写规则。比如在 gitolite.conf 中加一段：
repo myproject
RW+ refs/heads/main$ = admin
RW refs/heads/dev$ = devteam
R refs/heads/feature/.*$ = @all
- refs/heads/release/.*$ = @all
RW+ refs/heads/release/.*$ = releaseteam意思是：所有人能读 feature/ 开头分支；但 release/ 下所有分支默认禁止任何操作，只有 releaseteam 组能推和改。
日常办公中这些场景很实用
• 财务系统上线前，把 prod 分支设为「仅运维可推」，开发只能提 PR，由运维人工审核后合并
• 新员工刚入职，先限制他只能向 dev 推送，等熟悉流程后再开放 test 分支权限
• 市场活动页紧急上线，临时开一个 hotfix-20241015 分支，只允许两位前端负责人推送，避免多人乱改
权限不是卡着大家干活，而是让流程稳下来。哪天你发现同事不再随口说“我直接 push 到 main 了”，而是老老实实点开 PR 页面写描述、@ 相关人评审——那说明分支权限真起作用了。