GitHub Pull Request 怎样设置必需评审人

GitHub PR里手动添加Reviewer只是请求评审。要让改动必须经过对应负责人批准，需要先用CODEOWNERS指定文件负责人，再在目标分支的保护规则中启用“Require review from Code Owners”。必需批准数量控制人数，CODEOWNERS控制哪些负责人有资格满足对应要求。

官方地址：https://github.com/

下面使用经典分支保护界面，以main为合并目标。需要管理员权限或具备编辑仓库规则的自定义角色；是否可用还取决于仓库可见性与账户方案。如果组织已用Rulesets统一管理，请由维护者在现有规则体系中配置同类要求，避免再建一套相互影响的策略。

1. 在目标分支提交 CODEOWNERS

打开仓库的Code → 分支选择器，切换到main。在文件区选择Add file → Create new file，文件名输入.github/CODEOWNERS。已有文件时直接打开并编辑它。填写路径与负责人后点击Commit changes，按现有流程提交变更并合并到main。

以下是示意配置，@demo-maintainer和@demo-api-owner必须换成仓库中真实、有写权限的账号；不要原样提交占位账号：

# 默认文件由维护负责人评审，后面的匹配行可覆盖前面规则。
* @demo-maintainer
# API目录由该目录负责人评审。
/services/api/ @demo-api-owner
# 同时保护负责人配置文件自身。
/.github/CODEOWNERS @demo-maintainer

完成后，main的文件树中应能找到该文件。配置由PR的base分支读取；只把CODEOWNERS放到尚未合并的功能分支，不能当作目标分支已经生效。路径区分大小写，最后一条匹配规则优先；多个负责人若写在同一条路径后，通常是其中任意一人批准即可，不能理解为所有人都必须批准。

团队作为负责人时，团队需要可见并显式拥有仓库写权限。修改成员本身的访问权限，不一定等于该团队已被授予所需权限。账号不存在或权限不足，会导致负责人未被分配。

2. 为合并目标分支启用必需批准

打开仓库Settings → Code, planning, and automation → Branches。在Branch protection rules区域点击Add classic branch protection rule；如果main已有规则，则进入对应规则的Edit，避免重复创建。

在Branch name pattern中填main，勾选Require a pull request before merging和Require approvals，将必需批准数量设为1，再勾选Require review from Code Owners。首次创建点击Create，编辑已有规则点击Save changes。

返回规则列表后，应看到main规则；再次打开它可以查看刚保存的选项。分支匹配的是PR合并目标，而非开发分支名字。经典分支保护同一时刻只应用一条匹配规则，已有更高优先级规则时，应先确认有效规则，不能靠不断添加通配符解决。

根据团队制度决定是否启用新提交后撤销旧批准，或要求最近一次可评审推送由其他人批准。它们解决的是“批准后又改代码”的情况，和首次要求负责人批准不同。管理员或具有绕过权限的角色可能不受一般限制；若要求统一执行，应评估并配置Do not allow bypassing the above settings及相关例外，而不是只看普通成员的体验。

3. 在 Pull Request 中确认评审要求

在仓库Pull requests → New pull request中确认base: main，选择含services/api/改动的测试分支，再创建普通PR。打开后查看右侧Reviewers区域以及页面底部合并区域：应能识别相应代码所有者，并在要求尚未满足时阻止普通参与者合并。若PR还是Draft，先点击Ready for review；草稿不会按普通PR方式自动请求代码所有者评审。

由负责人打开PR，进入Files changed → Review changes → Approve → Submit review。满足负责人要求与批准人数后，评审这一项应变为通过；CI、对话解决等其他限制仍可能阻止合并。不要为了确认配置而合并没有业务用途的测试改动，可以在检查状态后关闭测试PR。

能否只在Reviewer框里指定必需的人？

该框主要用于请求评审。要强制对应文件负责人批准，应把负责人映射与目标分支规则同时配置。

把必需人数设为2，就能强制两个指定账号吗？

人数与身份条件不同，不能由人数2推导两个固定账号都必须批准。若确需更细的团队审批政策，应由组织维护者评估可用规则功能，不能把普通CODEOWNERS同一行解释成全员会签。

官方资料：代码所有者与文件规则、经典分支保护设置。