GitHub 怎样让不同目录匹配不同审查人
来源:17golang原创
时间:2026-10-17 23:14:47 435浏览 收藏
在 GitHub 仓库里,不同目录可以由不同的人或团队负责审查。最直接的做法是维护一份 CODEOWNERS 文件:先写一个全仓库兜底规则,再用目录和文件类型规则覆盖它,最后让更具体的路径排在后面。
官方入口:https://github.com/
规则说明:https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
本文示例只解决“不同目录匹配不同审查人”这一件事。关键有三点:文件优先放在 .github/CODEOWNERS,同一文件的最后一个匹配规则优先,规则中的用户或团队必须对仓库拥有写入权限。
先把 CODEOWNERS 放在正确位置
打开目标仓库,进入默认分支,按“仓库首页 → Add file → Create new file”的路径新建文件。文件名输入 .github/CODEOWNERS,不要写成 CODEOWNERS.txt。GitHub 也支持把它放在仓库根目录或 docs/ 目录,但多个位置同时存在时,会优先使用 .github/ 下的文件。
先放入一条最小规则,再点击“Commit changes”提交到拉取请求的 base 分支。提交后,回到仓库文件列表,确认能打开 .github/CODEOWNERS,这就是文件入口已经生效的可见状态。

先写兜底规则,再写目录规则
CODEOWNERS 的每一行由“匹配模式 + 一个或多个审查人”组成。下面用占位团队名演示一个小型仓库,实际使用时替换为你组织中真实存在且有写入权限的用户名或团队:
# 所有未被更具体规则覆盖的文件,交给基础团队
* @your-org/repository-reviewers
# docs 目录及其子目录由文档团队负责
/docs/ @your-org/docs-reviewers
# Go 文件统一交给后端团队
*.go @your-org/backend-reviewers
# API 文档比普通 docs 更具体,交给 API 团队
/docs/api/ @your-org/api-reviewers
这里的 /docs/ 指仓库根目录下的 docs 目录;*.go 匹配 Go 文件;/docs/api/ 只把 API 子目录单独分给另一个团队。团队写在同一行时表示这些团队都属于该规则的所有者,满足所需审查时通常任一所有者的批准即可。
用规则顺序解决“匹配错人”
CODEOWNERS 不是“先匹配先结束”,而是让最后一个匹配的模式拥有更高优先级。假设拉取请求修改了 docs/api/client.go,它会同时命中 *、/docs/、*.go 和 /docs/api/,最终应由最后一行的 API 团队接收审查请求。
因此,规则建议按下面的顺序维护:
- 第一段写仓库级兜底团队。
- 第二段写普通目录和文件类型。
- 最后写需要特殊处理的深层目录或单个文件。
在仓库文件页面打开 CODEOWNERS 后,检查规则是否仍按“通用在前、具体在后”排列。然后创建一个只修改目标目录文件的测试拉取请求,在右侧审查区域查看 GitHub 请求的团队是否与最后匹配规则一致。下面的图是这个界面状态的原创说明,不代表真实仓库已经运行。

常见的不生效原因
- 文件在错误分支:拉取请求使用 base 分支上的 CODEOWNERS,不能只把文件放在 head 分支里。
- 审查人没有写入权限:用户名或团队必须真实存在,并且对该仓库有写入权限;团队还需要具备可被 GitHub 使用的可见性。
- 规则写反了:更具体的规则放在通用规则前面,后面的通用规则可能再次覆盖它。
- 把 gitignore 语法全搬过来:CODEOWNERS 不支持用
!做否定匹配,也不支持字符范围写法;路径大小写也要和仓库中的实际路径一致。 - 没有启用强制审查:CODEOWNERS 可以自动请求审查,但是否必须由代码所有者批准,还要由仓库维护者在分支保护规则或规则集中开启相应要求。
提交前的快速确认
最后按这张小清单检查:文件位于 .github/CODEOWNERS;兜底规则在前、特殊目录在后;每个用户名或团队有写入权限;规则使用仓库真实路径和正确大小写;测试拉取请求修改了目标文件;审查区域显示了最后匹配到的团队。这样就能把“不同目录由不同人审查”落实为可读、可维护的仓库规则。
相关问题
同一条规则能写多个审查人吗?
可以,把多个用户名或团队写在同一行。不要把同一模式拆成多行,否则通常只有最后出现的所有者会被视为该模式的匹配结果。
为什么文件明明匹配,却没有自动请求审查?
先确认 CODEOWNERS 在 base 分支、路径大小写正确、所有者拥有写入权限,并检查该拉取请求是否仍处于草稿状态。草稿拉取请求不会自动请求代码所有者审查,标记为准备审查后再看右侧状态。
-
455 收藏
-
431 收藏
-
124 收藏
-
311 收藏
-
462 收藏
-
126 收藏
-
282 收藏
-
363 收藏
-
392 收藏
-
324 收藏
-
193 收藏
-
462 收藏
-
108 收藏
-
476 收藏
-
248 收藏
-
234 收藏
-
222 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习