Git分支权限控制在团队开发中的实现-git-PHP中文网

git本身不支持分支级权限控制，必须依赖托管平台（如gitlab、github、gitee）在服务端校验；gitlab通过protected branches、github通过branch protection rules、gitea/gitolite通过配置或钩子实现，且需注意force push默认不受限。

git分支权限控制在团队开发中的实现

Git 本身不支持分支级权限控制

Git 是一个分布式版本控制系统，本地仓库拥有完整历史，服务端（如 GitLab、GitHub、Gitee）才负责访问控制。单纯用 git 命令或本地配置无法限制某人 push 到 main 或 release/* 分支——这些规则必须由托管平台在接收 push 时强制校验。

GitLab 中配置 protected branches 是最常用方案

GitLab 提供细粒度的分支保护机制，能限制谁可以 push、merge、删除分支，还能要求 CI 通过、代码审查等前提条件。

进入项目 Settings → Repository → Protected branches
添加要保护的分支模式，例如 main、release/*、hotfix/**
设置 Allowed to merge 和 Allowed to push 角色（如 Maintainer、Developer、No one）
勾选 Require a pull request before merging 或 Require approval from code owners 可强化流程
注意：保护规则对已存在的分支立即生效，但不会自动拒绝本地 git push —— 错误会在 git push 上传时由 GitLab 返回 remote: You are not allowed to push code to this branch.

GitHub 的 branch protection rules 功能类似但命名不同

GitHub 把对应功能叫 “Branch protection rules”，位置在 Settings → Branches → Add rule，逻辑一致但参数更结构化。

Github Private Repo SSH Routing

在多仓库环境中诊断并管理 GitHub 私有仓库的 SSH 密钥、主机别名和 Git 远程地址。适用于部署密钥冲突、机器……

下载

Pattern 支持 main、releases/** 等通配符（注意 GitHub 不支持 ** 多级通配，releases/* 只匹配一级子目录）
必须开启 Require pull request reviews before merging 才能指定 reviewer 数量和权限
Include administrators 默认勾选，意味着 repo admin 也会受规则约束 —— 若需管理员豁免，必须手动取消该选项
若启用 Require status checks to pass before merging，CI 状态名必须与 GitHub Actions 中 jobs.<job-id>.name</job-id> 或第三方 CI 配置完全一致，否则规则不生效

自建 Git 服务器（如 Gitea、Gitolite）需额外脚本或钩子

开源托管平台如 Gitea 支持类似 GitLab 的 UI 配置；而极简方案如 Gitolite，则依赖 conf/gitolite.conf 中的正则权限声明：

repo myproject
    RW+     =   @admin
    RW      refs/heads/main$ =   @dev
    -       refs/heads/main$ =   @guest
    RW      refs/heads/feature/.* =   @dev

注意：$ 表示行尾锚定，漏写会导致误匹配；- 表示显式拒绝，优先级高于 RW；所有规则按顺序匹配，第一条命中即终止。

真正容易被忽略的是：分支保护只拦 push，不拦 force push —— 除非平台明确开启「禁止强制推送」选项（GitLab 默认关闭，GitHub 默认开启）。一旦允许 force push，任何有 push 权限的人都可能覆盖保护分支的历史。