Git仓库权限由平台（GitHub/GitLab等）控制，需配置分支保护规则、角色权限及安全凭据；PHP项目本身不处理权限。
Git 仓库里怎么给不同人设 PHP 项目权限
PHP 项目本身不管理权限，权限在 Git 仓库层（如 GitHub、GitLab、Gitee 或自建 Git 服务器）控制。你真正要配的是：谁可以 git push 到哪个分支、谁只能 git pull、谁能看到私有仓库。
- GitHub/GitLab 上没有“PHP 开发者组”这种内置角色——得靠「仓库 Collaborators」或「Group/Project Roles」手动分配
- 别在
composer.json或.env里写权限逻辑，那不是权限系统，是配置泄漏风险 - 如果用自建 Git（比如 gitolite 或 Gitea），权限规则写在配置文件里，例如
conf/gitolite.conf中按分支限制rw+和R
GitHub 上禁止直接 push 到 main 分支的实操设置
这是 PHP 团队最常漏掉的一环：没开保护分支，导致有人 git push --force 破坏 CI 流水线或 Composer 自动加载映射。
- 进仓库 Settings → Branches → Branch protection rules → Add rule
- Branch name pattern 填
main（或master，看你们约定） - 勾选
Require a pull request before merging和Include administrators（连 Owner 也不能绕过） - 可选但推荐：勾选
Require status checks to pass before merging，关联 GitHub Actions 的composer install+phpstan检查
GitLab 中用 Protected Branches 控制 PHP 部署分支
很多 PHP 项目用 production 分支自动部署到线上，但默认任何人都能推——这等于把数据库密码直接贴在 README 里。
- Settings → Repository → Protected branches
- 选中
production，将 “Allowed to merge” 设为 “Maintainers”，“Allowed to push” 设为 “No one” - 这样只有 Maintainer 能合并 MR 到
production，且必须经过 CI（比如phpunit全通过 +php-cs-fixer --dry-run无变更） - 注意：
developer角色默认不能 push 到 protected 分支，但能创建 MR——这点和 GitHub 的 “Triage” 角色行为不同，容易误判权限范围
用 deploy keys 还是 personal access tokens 做自动化部署
CI/CD 脚本（比如 GitHub Actions 的 .github/workflows/deploy.yml）拉代码、打 tag、推镜像时，用错凭据会导致权限过大或失效。
立即学习“PHP免费学习笔记（深入）”；
- 别用个人
Personal Access Token（尤其带reposcope）硬编码进 workflow，泄露即全库沦陷 - 优先用 GitHub 的
GITHUB_TOKEN（自动注入，scope 受当前 workflow 权限限制），它默认对本仓库有read:packages和contents:write - 如果要部署到外部 Git（比如把构建产物推到另一个只读镜像仓库），用 deploy key（SSH key）并限制为
writeonly 到特定 repo，比 token 更细粒度 - GitLab CI 用
CI_DEPLOY_PASSWORD配合git clone https://user:$CI_DEPLOY_PASSWORD@gitlab.example.com/group/project.git，但记得在 CI 设置里勾选 “Mask variable”
权限不是设一次就完事的事——每次加新人、换 CI 工具、切新分支，都得回头检查 protected branches 和 token scope。最容易被忽略的是：管理员自己开了 bypass 选项，结果忘了关。
