GitHub允许Triage及以上角色归档拉取请求

GitHub 这次变更的核心不是增加一种新的合并方式，而是下放拉取请求（Pull Request，简称 PR）的归档权限：仓库中的 Triage、Write、Maintain 和 Admin 角色现在都可以归档或取消归档 PR。归档后，PR 会自动关闭并进入只读状态；取消归档只恢复评论和反应能力，不会自动重新打开 PR。

官方地址：https://github.blog/changelog/2026-10-08-triage-role-users-or-higher-can-now-archive-pull-requests/

这次变化解决了什么问题

过去，归档 PR 主要依赖仓库管理员。对于垃圾、重复或长期无人处理的 PR，受信任的 Triage 协作者即使负责日常队列维护，也要把最后一步交给更高权限的人。现在，GitHub 把“整理会话”与“修改代码”的权限边界分开：Triage 可以完成归档动作，但并不因此获得提交代码或改变锁定状态的能力。

哪些角色现在可以归档 PR

公告列出的可用角色是 Triage、Write、Maintain 和 Admin。判断团队成员能否执行操作时，先看其在目标仓库中的最高有效角色，不要只看组织成员身份或某个团队名称。低于 Triage 的角色不在这次公告列出的范围内，文章也不据此推断其他自定义权限会获得同样能力。

对维护者来说，比较实用的分工是：把重复、垃圾或已放弃的 PR 交给 Triage 角色归档；把需要改代码、改变仓库设置或处理复杂权限的问题，仍留给拥有相应能力的角色。这样做能减少队列清理对管理员的依赖，同时避免把代码变更权限一并放大。

归档后会发生哪些状态变化

归档不是简单地把 PR 从列表里折叠起来。GitHub 公告明确了四个结果：PR 会自动关闭；会话变为只读；新的评论、反应和自动评论都会被阻止；PR 会从公开视图隐藏，但 Triage、Write、Maintain 和 Admin 角色仍可查看。

这意味着归档适合表达“这个讨论暂时不再接受新活动”，而不是表达“问题已经解决”。如果团队仍需要保留上下文，可以先归档再按需取消归档。取消归档会恢复评论和反应能力，但不会把 PR 重新打开；是否重新打开应由维护者根据代码状态和团队流程单独决定。

团队可以怎样落地这项变化

可以把操作流程收敛成三个判断。第一，先确认 PR 属于垃圾、重复或已经放弃的队列项，而不是仍在等待评审的正常变更。第二，由 Triage 或更高角色执行归档，并把原因留在团队自己的记录中。第三，如果后续需要继续讨论，先取消归档，再单独判断是否要重新打开；不要把“可评论”误解为“已恢复到打开状态”。

需要注意的是，公告只说明 GitHub 对归档 PR 的权限和状态处理，不等于为每个组织定义了统一的审批制度。是否必须先标记、通知作者或保留外部记录，仍应由仓库维护规则决定。

常见问题

Triage 角色可以归档和取消归档 PR 吗？

可以。公告列出的 Triage、Write、Maintain、Admin 都具备这两项能力。

取消归档后 PR 会自动重新打开吗？

不会。取消归档恢复评论和反应，但 PR 仍保持关闭状态，是否重新打开需要另外操作。

归档后的 PR 公众还能看到吗？

公告说明归档 PR 会从公开视图隐藏，同时对 Triage、Write、Maintain、Admin 角色保持可见。