Git分支模型本身无权限控制能力，权限由托管平台在服务端拦截校验；本地分支创建（如git branch）不受限制，仅git push等网络操作受protected branches等规则约束。
Git 分支模型本身不带权限控制能力，所有分支操作默认由 Git 客户端执行，权限实际由托管平台（如 GitLab / GitHub）在服务端拦截和校验。模型和权限“不对齐”，本质是混淆了 Git 的分布式语义与平台的集中式管控边界。
Git 本地分支创建不受任何平台权限限制
只要能 clone 仓库，git branch、git switch -c、git checkout -b 都能无阻碍执行——这些命令只操作本地 .git 目录，不发 HTTP 请求，平台无从干预。常见误判是：以为 Developer 角色不能建 feature/xxx 分支，其实能建，只是推不上去。
- 真正被拦住的是
git push，不是git branch - 分支命名规范（如是否允许
feature/前缀）靠protected branches规则或 CI 脚本拦截，不是 Git 内置机制 - 本地
git merge或git rebase永远成功，哪怕目标分支在远程已被保护
GitLab 中 protected branches 和角色权限是两套独立系统
比如你给某人分配 Developer 角色，他仍无法向 main 推送，因为 main 是 protected branch，且其 Allowed to push 设置里没包含 Developer。角色决定“能做什么操作”，protected branch 决定“对哪些分支能做该操作”——二者是 AND 关系，不是 OR。
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
-
maintainer角色默认有push权限，但若develop分支被设为 protected 且Allowed to push只勾选maintainers，那developer就连git push origin develop都会失败 - 保护分支可单独配置
Allowed to merge，这和Allowed to push不绑定；一个分支可以允许 Developer 合并 PR，但禁止其直接推送 -
CODEOWNERS文件进一步叠加一层审批逻辑，它不看角色，只认文件路径 + 提交者邮箱匹配
二次开发场景下分支模型必须显式映射到平台权限组
当你基于开源项目做定制时，典型结构是：upstream/main（上游）、origin/main（你的生产）、origin/staging（集成测试）、feature/*（定制功能）。这时权限不能只按“Developer/Maintainer”粗放分配，而要拆成权限组：
- 上游同步组：只允许
git fetch upstream+git merge upstream/main，禁止向upstream/*推送（根本没权限） - 定制发布组：可向
origin/main发起合并请求，但需CODEOWNERS中指定的定制负责人 approve - 功能开发组：仅允许向
feature/*推送，git push origin feature/login成功，但git push origin main必败
这种分组必须在 GitLab 群组中手动建 Custom Dev Team、Upstream Sync Team，再把人加进去，并为每个分支设置对应的 protected branches 规则——模型画得再漂亮，不落地到平台权限组，就是纸面流程。
最容易被忽略的是：protected branches 的 Allow force push 默认关闭，但某些自动化脚本（如版本号自动 bump）需要它；一旦开启，就绕过了所有基于提交历史的保护逻辑。这个开关不是“开或关”的问题，而是“谁能在什么条件下开”的问题——它必须和 CI job 的 service account 权限绑定，而不是给人账号开。
