GitHub 拉取请求限制新增哪些贡献者豁免条件

GitHub 在 2026 年 10 月 28 日公布了拉取请求限制的一项更新：管理员现在可以按贡献者的账号年龄，或按其在当前仓库已经合并的 Pull Request 数量，设置超出上限的豁免条件。两条规则只要有一条被启用且达到阈值，贡献者就可以不受该上限影响。

官方地址：https://github.blog/changelog/2026-10-28-pull-request-limits-exempt-contributors-by-age-or-history/

这项变化的重点不是取消拉取请求限制，而是把“所有无写权限贡献者使用同一上限”改成了“新贡献者仍受保护，已经建立一定信任的贡献者可以继续贡献”。

拉取请求限制解决的是什么问题

拉取请求上限主要用于控制无写权限用户提交贡献的数量。当一个仓库收到大量低信任或高频贡献时，维护者可以通过 Interaction limits 降低待处理请求的压力；但固定上限也可能误伤长期参与项目、持续提交有效改动的贡献者。

这次新增的能力把“限制”与“信任信号”拆开配置。账号年龄代表账号已经存在了一段时间，已合并 PR 数量则代表贡献者在这个仓库里有过被接受的改动。它们都是豁免依据，不等于 GitHub 代替维护者判断代码质量。

两种豁免条件如何判定

管理员可以在组织或仓库的 Moderation → Interaction limits 设置中启用一种或同时启用两种规则，并为每种规则填写阈值。

• 账号年龄：账号年龄达到管理员设置的最小天数后，贡献者获得豁免。阈值单位是天。
• 已合并 Pull Request：贡献者在该仓库中已经合并的 PR 数量达到设置值后，获得豁免。

两条规则之间是“满足任一即可”的关系。例如，管理员同时启用“账号至少存在 90 天”和“该仓库至少合并过 2 个 PR”，那么满足其中任意一项的贡献者就可以超过拉取请求上限。没有达到任何已启用阈值的贡献者，仍按原来的上限处理。

仓库级设置为什么要优先检查

公告还明确了配置的作用域：组织可以提供一套默认限制，但仓库级拉取请求上限设置会覆盖组织级设置。因此排查“为什么这个仓库的限制和组织默认值不一样”时，应先看仓库自身的 Interaction limits，再回到组织设置。

GitHub 还保留了现有的单独豁免列表。它适合处理少量明确的例外人员；年龄和合并历史规则则适合把可解释、可复用的信任条件交给系统自动判断。两者可以配合使用，但不要把个人名单当成组织规则的替代品。

管理员可以怎样落地这项变化

第一步先确认限制的目标：如果主要是防止新账号批量提交，账号年龄规则更贴近目标；如果项目更看重真实贡献记录，可以优先考虑已合并 PR 数量。两者同时启用时，要把它理解成放宽路径增加，而不是两个门槛叠加。

第二步按作用域检查配置。组织管理员负责默认策略，仓库维护者则需要确认本仓库是否覆盖了组织设置，以及阈值是否符合维护能力。第三步保留一条人工处理路径：对已经确认可信、但暂时不满足自动规则的贡献者，可以使用现有的单独豁免列表。

最后，记录规则的意图和阈值变更原因。账号年龄和合并数量只能说明部分历史，不能代替代码审查、权限控制或社区治理。对于高风险仓库，放宽上限后仍应保留审查、CI 和分支保护等原有门禁。

常见问题

两条豁免规则必须同时满足吗？不需要。只要至少一条已启用规则达到阈值，贡献者就可以获得豁免。

账号年龄是按整个 GitHub 账号计算吗？公告把它定义为账号达到设置的最小年龄，单位为天；它不是当前仓库的注册时间。

仓库级设置和组织级设置冲突时看哪一个？看仓库级设置，因为公告明确说明仓库级拉取请求上限会覆盖组织级设置。

这项变化会自动关闭拉取请求限制吗？不会。它增加的是可配置的豁免规则，限制本身仍由管理员在 Interaction limits 中设置。