先聊个很基础但几乎人人都要面对的问题GitHub上怎么查看PR。别觉得这问题太小我见过不少写了几年代码的同事找自己的PR还在仓库里一个个翻 commits被分配了 review 任务也不知道入口在哪。PR 在协作流程里是日常最核心的动作只看懂能打开详情页完全不够得把查看的入口、标签、命令行手段都摸清楚才能真正高效。这篇内容适合所有用 GitHub 做协作的人包括学生、自由开发者、以及刚加入团队还不太熟悉 GitHub 操作的新人。我尽量不绕弯子直接按场景拆把查看 PR这件事掰开揉碎了讲清楚。1. 先搞懂 PR 在 GitHub 里的角色再谈怎么看很多人打开 PR 页面觉得信息很乱是因为没搞明白 PR 到底是什么。它既是一段代码改动的载体也是一个完整的协作流程入口。理解了这个你就知道该在哪个页面找什么。1.1 Pull Request 不是一条消息而是一扇门PR也就是 Pull Request本质上是你告诉项目维护者我这边有一批改动请你审核后把它合入主线。它不是一个简单的聊天消息更像一扇门门后面挂着这次改动的所有提交记录、文件差异、自动化检查结果、讨论过程和最终的合并状态。所以查看 PR这个动作实际上是在查看一整套流程的当前进度。你会看到它处于什么状态、改动了哪些文件、CI 跑得怎么样、有没有人 review、最后是被合并还是被关闭。新手如果只盯着页面顶部的标题描述看就等于只看到了门上的铭牌里面的东西一点没看到。我自己的理解是把 PR 当成一个项目现场。你要看的不是它叫什么而是它的施工进度。这个思维一旦建立下面的所有查看技巧就顺理成章了。1.2 先判断你是哪一种角色再决定查什么同样是查看 PR不同身份的人关心的重点完全不同入口也有差异。我把常见的场景分成三类你可以对号入座提交者你发起了 PR需要看 CI 是否通过、有没有被 review 意见打回、是否被合并。重点在状态流转和反馈。评审者别人发来 review 请求你需要看代码差异、提修改意见、做 approve 或 request changes。重点在 Files Changed 和行内评论。围观者你只是想知道某个 PR 做了什么改动、为什么这么改或者要从历史 PR 里找灵感。重点在 Conversation 和 Commits。三种角色对应的最佳入口并不完全一样。很多人只会在仓库的 Pull requests 列表里翻这其实是最通用的方式但不是最快的。下面几节我按这几种身份分别讲。2. 提交者怎么快速找到自己提交的 PR先解决一个最简单也最常被问的问题我自己刚提了 PR为什么回头就找不到不是丢了是你没找对地方。2.1 仓库列表页的筛选不要靠肉眼滚动仓库首页顶部的 Pull requests 标签打开后默认展示的是所有开着的 PR。如果你在一个活跃的仓库里这里通常滚动半天也看不到自己的。正确做法是用筛选框。在 Pull requests 列表页左侧有一个带提示的搜索框你可以在里面输入author:你的用户名它会自动过滤出你提交的所有 PR。如果 PR 已经合并或者关闭了记得点击页面上方的 Closed 标签再用同样的过滤器查看。另外列表页还支持 assignee指派人和 reviewer评审人筛选这个后面评审视角再展开。我实际用下来还有一个很省事的组合直接在搜索框里写is:open author:你的用户名可以一眼看出手上还有哪些没被处理。如果你是几个仓库的协作者这种筛选优于挨个仓库看。2.2 个人首页的 Your pull requests 入口GitHub 登录后的首页右上角头像菜单里有一个 Your pull requests 项。点进去后是全局视角能跨仓库看到你做过的所有 PR。这个页面顶部有五个 tab 分类Created你发起的 PRAssigned指派给你处理的 PRMentioned提到过你的 PRReview requests请求你 review 的 PR对提交者来说直接用 Created 就行。我建议把个人首页这个入口记下来因为在多仓库协作时它比一个个仓库去找快太多了。很多人不知道这个入口总是从组织或仓库页绕路实测效率差好几倍。2.3 直链访问PR 的编号就是它的门牌号如果你知道 PR 的编号最快的方式当然是直接输入 URL。格式非常简单https://github.com/用户名/仓库名/pull/编号比如https://github.com/git/git/pull/1234。编号可以从邮件通知里复制也可以从个人首页的 PR 列表里拿鼠标悬停看状态栏。我见到有朋友会把 PR 链接直接写在群聊里对方点开就能看这个习惯非常好比说帮我看看那个改动要清晰得多。有一点要注意PR 编号是仓库全局递增的不是按年份或分支重置。即使那个 PR 被关闭了链接依然有效。所以看到老的链接打不开先检查仓库地址是否拼写正确然后确认权限。3. PR 详情页五个关键区域一个都不要漏打开 PR 详情页后上方有几个标签Conversation、Commits、Checks、Files Changed。多数人只会盯 Conversation但真正有价值的信息分散在所有标签里。下面按我的查看习惯逐个拆。3.1 Conversation 标签时间线里藏着最终结论Conversation 是 PR 的默认展示页也是讨论、状态流转的总记录。这里会展示 PR 的标题、描述、参与者的评论、reviews 的结论以及合并事件的时间线。我建议查看这个页面时重点看三个东西描述信息是否完整是否能解释为什么有这个 PR。是否有维护者或机器人留下的关键评论例如需求变更。页面下方的合并/关闭事件是哪个时间点发生的。如果你是在 review 一个 PR时间线可以帮你快速了解它的来龙去脉避免只盯着代码差异看。很多人跳过描述直接看 diff看似高效实际上容易漏掉重要背景。3.2 Commits 标签确认改动是怎么一步步来的Commits 标签列出这个 PR 包含的所有提交。这里能直接看到每个 commit 的提交信息、作者和对应的时间。对评审者来说我要提醒一个常见误区不要只看最后一个 commit要看完整的提交序列因为每个 commit 代表了一个逻辑步骤有时中间某一步改错了又被后面修复这种过程信息只在 Commits 里能看出来。点击任意一个 commit 的 hash可以单独查看那一次提交的具体差异。如果你发现 PR 里有不该出现的文件变更比如把配置文件或依赖锁文件顺手带进来了通常就是在某次 commit 的 diff 里暴露的。3.3 Files Changed 标签diff 视图的核心用法Files Changed 是评审者最常待的界面也是新手最容易看懵的地方。页面顶部会给出一个汇总类似120 −15表示新增了 120 行删除了 15 行。紧接着是文件列表每个文件可以按 diff 视图逐行对比。绿色是高亮的新增行红色是删除行。默认情况下是按逐行对比的方式展示也可以在文件右上角切换成忽略空格或分词对比等模式。实际操作时你可以给单行或几行代码留下评论。把鼠标移到某一行左侧的号上悬停会出现一个评论图标点击后就能输入行内评论。这个功能在代码评审时是整个流程里最核心的手段。有一点经验分享如果 PR 涉及上千行改动不要试图在一个屏幕上看完所有 diff。先看文件列表圈定核心业务文件再进入逐个看。无关的生成文件或格式调整直接用Files changed页面上的跳过按钮。这样能避免diff 疲劳。我自己的习惯是按文件类型分优先级逻辑代码高优先测试代码其次配置和文档最后看。3.4 Checks 标签CI 跑没跑过直接决定能不能合在 GitHub 上CI 运行结果通常显示在每个提交的旁边也可能被安装在 Files Changed 页面底部。聚合的视图在 Checks 标签里最清楚你能看到每个检查项的状态例如单元测试、构建任务、覆盖率检查等。这里想分享一个排查经验当看到某个 check 是红色失败时不要只在 PR 页面反复刷新等结果点进 Details 跳到 CI 日志页面直接看报错信息。很多情况下日志里已经在末尾给出了明确的原因例如测试断言失败或构建缓存过期。另外一个细节是合并按钮是有条件的。如果仓库配置了 required checks所有必检项没通过时按钮是灰的通过了才会变绿可点。你查看 PR 状态时如果发现为什么不能合并多半要先检查 Checks 这一栏。4. 评审者视角别人请求我 review 的 PR 怎么高效看被分配 review 任务和主动去看别人的 PR感受完全不一样。前者是有压力的你有责任给出结论。我下面讲几个从被动接收到完成评审的关键操作。4.1 Review requests 从哪里出来请求你 review 的 PR 不会随便出现在你眼前它会出现在两个地方。一是 GitHub 首页如果你有新的 review 请求首页会出现一个类似收件箱的模块二是你的邮箱GitHub 发出的 review 请求邮件主题里一般带有标注一眼就能识别。如果你看不到提示可以主动去仓库的 Pull requests 列表页用过滤器找review-requested:你的用户名这个过滤器会列出所有等待你操作的 PR。注意一旦你提交了评审意见它就会从这个列表消失直到对方重新请求 review。这也是很多人以为找不到那个 PR 了的原因。4.2 行内评论和 Review 结论的区别在 Files Changed 页面里选中代码后可以直接留下评论。写完后右上角会有一个 Review changes 按钮点开后可以选择三种结论Comment普通评论不影响合并状态。Approve表示同意合并。Request changes表示需要修改合并按钮会被冻结。我强烈建议发出 Request changes 时在总结里写明需要改什么、为什么改最好也指出对应文件或行号。这能大幅减少沟通成本。实际团队协作中很多无效争论都源于结论写得太模糊比如只说这里逻辑不对对方根本不知道指的是哪一行为什么不对。4.3 本地拉取 PR 分支做实测只靠在网页上看代码 diff有时无法判断实际运行效果。遇到涉及交互逻辑或样式调整的 PR我建议把 PR 对应的分支拉到本地跑一把。最通用的命令是通过 fetch 指定 pull 编号git fetch origin pull/506/head:pr-506执行后你会得到一个本地分支pr-506然后切换过去git checkout pr-506如果你安装了 GitHub 官方命令行工具 gh还可以更简单gh pr checkout 506它会自动帮你创建并切换到对应的本地分支。实测结束记得切回原来的分支git checkout main如果你同时拉了好几个 PR 分支处理完可以按需删除。这个流程尤其适合测试类 PR 或需要跑前后端联调的场景。不过有一点要提醒PR 分支往往赶不上你本地其他分支的提交进度如果本地有其他未提交的改动先 stash 或者确认没冲突再切。5. 进阶玩法用命令行和 compare 链接精准查看 PR网页界面适合沉浸式查看命令行则适合快速检索和批量操作。这里分享几个我平时高频使用的命令和链接技巧。5.1 gh CLI 快速查看 PR 的三种姿势GitHub 官方工具gh装好后查看 PR 非常顺滑。最常用的三个命令是gh pr list gh pr view 506 gh pr diff 506gh pr list默认列出当前仓库所有打开状态的 PR加上--author 用户名就能只看指定提交者的gh pr view查看单个 PR 的标题、描述、状态和评论摘要gh pr diff直接输出这个 PR 的完整代码差异到终端。如果配合jq做解析gh pr list --json number,title,mergeable之类的命令可以输出结构化 JSON方便自己写脚本统计待处理 PR。说实话当你手里有十几个仓库要盯时这种批量查看方式比开浏览器一个个点不知道省多少时间。建议把gh作为标配工具装起来虽然界面和网页有重叠但在快速获取信息这个场景下它无可替代。5.2 compare 链接任意两点的 diff 一眼看全GitHub 还有一个常被忽略的比较页面URL 格式是https://github.com/用户名/仓库名/compare/main...feature-branch它会直接展示两个分支之间的差异而不用先建 PR。这在以下场景特别有用你还没确定要不要发 PR想先看看本地分支和主分支差了多少。你想对比某个 PR 合并前后的状态。你想跨过多个 PR 看整体变化。更细粒度的是你可以用 commit hash 替代分支名来精确比较任意两个历史节点。我经常在复盘线上问题时直接用这个链接对比发布前后的版本比翻一堆发布记录省事。5.3 从 commit 反查它属于哪个 PR有时你在主分支上看到一个 commit想知道它是通过哪个 PR 合进来的。GitHub 在 commit 详情页会显示一个 This commit belongs to pull request #xxx 的链接部分仓库可能不显示直接点就能跳转。如果你更习惯命令行也可以用gh pr list --search commit的hash或者用gh search commits做更精确的查找。这个反向追踪技巧在排查哪次改动引入了问题时特别好用。我就靠这个命令追查过好几个线上突然报错但不知道是哪个 PR 导致的的鬼问题。6. 整理几个我踩过的坑当成排查速查表给你最后把我在实际使用中遇到的典型问题列出来。这些问题看似很小但卡住的时候真的影响心情和效率。6.1 明明提交了 PR为什么列表里看不到最常见的原因是状态筛选不对。GitHub 的 Pull requests 列表默认只显示 Open 状态的 PR一旦被合并或关闭就不会出现在默认列表里。记得切换到 Closed 标签或者用is:merged过滤器。另一个容易忽略的点是仓库权限。如果你在 fork 的仓库里提交了 PR原仓库的 Pull requests 列表不会显示你的提交流程反之你得看 fork 出来的那个仓库或者在原仓库搜索author:你的用户名。6.2 网页加载缓慢或者白屏GitHub 偶尔会因为你本地网络环境或浏览器控制台插件的问题出现加载不出样式或内容的情况。我的处理顺序是先刷一次等待完整加载别急着点。换无痕模式或换个浏览器确认是不是缓存问题。禁用浏览器里可能与网页布局冲突的插件再试。这些是纯本地浏览器层面的操作不涉及任何非正规访问手段。普通情况下刷新两次就能解决。6.3 查看 PR 却看不到可以合并的提示如果你看不到合并按钮说明仓库管理员可能限制了合入条件。这种情况不是你看错了而是权限或检查项不满足。你可以检查 PR 是否处于 draft草稿状态草稿 PR 顶部会明确标注同时查看 required checks 是否都通过了。还有一种可能是仓库设置了 review 数量要求例如必须有两个 approve 才能合并。这时页面会显示当前有几个 approve你就能判断卡在哪了。6.4 手机上查看 PR 用什么方式GitHub 手机端的 App 已经能覆盖日常查看场景。在 App 里打开仓库拉到 Pull requests 标签页可以直接看列表、进详情、看 diff 和留评论。坦白说手机上的 diff 阅读体验对长文件不友好我更推荐它在快速确认 CI 状态、查收 review 请求、回复讨论这些轻量场景下使用。真正要逐行评审还是回到桌面浏览器或命令行。我自己现在的工作流是日常随手看用 App系统评审开电脑批量检索用终端gh。这三种手段互相补充基本覆盖了所有查看 PR的需求。最后再分享一个小习惯每次提交 PR 后我自己会把 PR 链接发到相关的群聊或者文档里给一个一句话的功能说明。这样别人不需要再去列表里大海捞针找人也顺手保留了这条改动是干什么的的上下文。看似多花了一分钟后面找人 review、复盘问题、追溯历史的时候能省下一个小时。这个习惯强烈建议你培养起来。