我完全懂你想要的分支权限控制逻辑——既要守住master分支的安全性，又得给自动化发布流程开绿灯，同时让团队成员能顺畅通过PR协作。好消息是，GitHub的Team计划完全能满足你所有需求，下面我一步步拆解具体实现方式：

1. 配置核心分支保护规则 #

先进入仓库的「Settings」→「Branches」→「Branch protection rules」，新建针对master分支的规则：

• 勾选「Require a pull request before merging」：强制所有人（除后续配置的例外账号）必须通过PR提交代码到master
• 勾选「Require approvals」，按需设置至少1个审批人：确保PR必须经过审核才能进入合并环节
• 先不要勾选「Restrict who can push to matching branches」——我们会用更精准的方式配置直接推送的例外

2. 给管理员和自动化账号开直接推送权限 #

接下来要让管理员团队、自动化服务账号（比如Jenkins的Maven release专用账号）能直接推master：

• 进入仓库的「Settings」→「Access」→「Collaborators and teams」：
  • 给管理员团队设置「Maintain」权限：这个权限允许成员直接推送受保护分支
  • 给自动化服务账号单独分配「Maintain」权限（如果是组织级的服务账号，也可以直接加到管理员团队里）
• 回到分支保护规则，找到「Allow specified actors to bypass required pull requests」选项，添加你的管理员团队和自动化服务账号：这会让这些账号跳过PR强制要求，直接向master推送代码

3. 确保所有人能合并已审批的PR #

默认情况下，只要PR满足了审批要求，所有拥有仓库「Write」权限的成员都可以合并PR——这正好符合你的需求。如果需要调整，可以检查仓库权限设置：

• 给普通团队成员分配「Write」权限即可：他们不能直接推master，但可以提交PR，在PR通过审批后完成合并操作

关于GitHub Team计划的支持性确认 #

GitHub Team计划完全支持上述所有功能：分支保护规则、PR审批要求、例外账号绕过PR限制、精细化的仓库权限分配（Maintain/Write等角色）。不需要升级到Enterprise计划就能实现你要的全部权限逻辑。

最后再梳理一遍最终的权限效果：

• 管理员和自动化账号：直接推送master ✅，提交并合并PR ✅
• 普通成员：必须提交PR → PR需审批 → 审批通过后可合并 ✅，无法直接推master ❌

内容的提问来源于stack exchange，提问作者raner