Agent官方动态GitHub AI2026年9月24日14 分钟阅读

在 GitHub Copilot 应用程序中呈现巨大的拉取请求

我们如何在 GitHub Copilot 应用程序中重建 diff 界面，以打开包含数百条内联审核评论的百万行拉取请求。在 GitHub Copilot 应用程序中渲染巨大的拉取请求一文首先出现在 GitHub 博客上。

Rendering huge pull requests in the GitHub Copilot app：长流程 Agent 时间线、任务节点与时钟 — AGENT / TIMELINE#25

发布来源

来自 GitHub AI 的官方动态，版本与适用范围以发布方说明为准。

GitHub AI · 查看官方发布

中文机器翻译 · 原文附后

正文 · 来源原文

首席设计工程师

广泛的重构和迁移通常必须作为一项变更来实施。

堆叠拉取请求是将工作拆分为更小的更改的好方法，这使得审查更容易，并帮助团队降低风险。但有些变化，比如这个，不能完全分开。这给你留下了一个可能变得非常大的拉取请求，而审查对话会导致它增长。

即使差异及其对话巨大，审阅体验也需要保持快速和流畅。在 GitHub Copilot 应用程序中，我们根据该要求重建了拉取请求视图。

为了看看能走多远，我们提出了我们能找到的最大的拉取请求：一个开源请求，包含 2,200 个文件、超过一百万行的更改行以及超过 400 条内联审核评论。以下是我们如何使这种极端的拉取请求变得高性能。

问题的范围

快速渲染大差异是很好理解的：虚拟化行，保持安装的 DOM 小，并依靠每行都是已知高度的一行代码这一事实。

评论是最难的部分。评论的高度取决于其降价方式、可扩展部分、是否有回复框以及图像是否已加载。您可以在渲染时发现所有这些。这迫使我们采用不同的架构。

三个问题：

测量。在渲染之前，您无法知道评论有多高。这打破了让大差异在滚动时保持响应的设计。数据管道。如果提供给它的数据管道停止，或者如果它丢弃了已经完成的工作，那么快速差异表面就没有价值。我们实际上是如何发现错误的。这些问题在负载下、在特定引擎上、在特定滚动位置处显现出来。因此，我们定义了健康的含义，对表面进行检测来回答它，并在无人值守的情况下运行整个变更→测量→改进循环。

第 1 部分：虚拟化，以及为什么评论会破坏它

第一步是了解使仅代码差异快速进行的几何结构。一旦评论出现，几何图形就不再足够了。

是什么让大差异变得更快

您无法在一个页面上放置一百万个 DOM 节点。标准答案是虚拟化：仅安装屏幕上的行，加上一个小边距，并在用户滚动时回收这些相同的 DOM 元素。该列表的行为就像所有百万行都存在一样。滚动条大小合适，滚动到行有效。但同时只有大约 100 行是真实的。

为了维持这种错觉，必须有某种东西来提供几何形状。滚动条高度是所有行高度的总和。第 N 行的位置是其上方各行高度的总和。跳到一行，绘制滚动条，决定屏幕上显示的内容，这都是高度表上的算术。您可以根据估计构建该表，并在测量行时对其进行更正，通用可变高度虚拟器正是这样做的。

但如果每一行都是已知字体大小的一行代码，则不必这样做。您可以预先计算整个表格，并且它永远不会改变，因此以后无需更正。

将此称为“油漆前已知的所有高度”合同。我们的 diff 表面是围绕它构建的：

一个命令式的、回收的代码行渲染器（每行没有 React 组件）用于偏移数学的类型化数组几何图形后端拥有的 diff 文档流结构优先具有精确“滚动到第 N 行”的命令式滚动 API

查看英文原文

Rendering huge pull requests in the GitHub Copilot app

How we rebuilt the diff surface in the GitHub Copilot app to open a million-line pull request with hundreds of inline review comments. The post Rendering huge pull requests in the GitHub Copilot app appeared first on The GitHub Blog .

正文 · 来源原文

Principal Design Engineer

Broad refactors and migrations often have to land as one change.

Stacked pull requests are a great way to split work into smaller changes, which makes reviews easier and helps teams ship with less risk. But some changes, like this one, can’t be split cleanly. That leaves you with a single pull request that can get very large, and the review conversation causes it to grow.

The review experience needs to remain fast and smooth even when the diff and its conversation are enormous. In the GitHub Copilot app, we rebuilt the pull request view with that requirement in mind.

To see how far that goes, we opened the biggest pull request we could find: an open source one with 2,200 files, over a million changed lines, and more than 400 inline review comments. Here’s how we made even this extreme pull request performant.

The scope of the problem

Rendering a large diff at speed is well-understood: virtualize the rows, keep the mounted DOM small, and lean on the fact that every row is a line of code at a known height.

Comments are the hard part. A comment’s height depends on how its markdown wraps, the expandable sections, whether there’s a reply box in it, and whether its images have loaded yet. You find all of that out at render time. This forces a different architecture.

测量调度程序，以及我们首先犯的错误

这部分花了最长的时间才完成，因为我们的第一个设计在启发性方面是错误的。

测量动态内容的明显方法是每个块一个 ResizeObserver，它监视元素并在元素发生变化时将其测量的高度写回到布局中。这是我们设计的，然后在性能强化过程中被拒绝的。这是大型虚拟化表面必须避免的反馈循环。将高度写回其正在观察的元素的布局中的观察者可以重新触发自身，并且成本随着每个安装的块而增加。

相反，提供的是单个空闲和滚动门控测量通道，与确定性方面遵循相同的规则：

脱离热路。它在可见范围稳定时运行，每个滚动帧不会运行一次，并且在滚动飞行时完全等待。滚动中间的回流正是我们要避免的卡顿。滚动停止后它会再次运行。范围限定为视口。只有视口大约 2400 像素范围内的块才是候选块，因此工作时间为 O(视口)。远处的方块会继续遵循它们的估计，并在接近时得到纠正。屏幕上的读数获胜。屏幕上显示了已安装的块，因此其渲染高度是真实高度。该通道会批量读取每个已安装的候选者，一次回流，中间没有写入，并记录它找到的内容。永远不会为了过时的估计而跳过已安装的块。该规则修复了我们遇到的最令人讨厌的错误：注释在下面呈现出一条空白，因为安装的块已被过滤掉测量值并留在太高的估计上。离屏测量是一种有限的后备方案。对于尚未安装的附近块，通道最多执行一次离屏渲染，以在滚动到视图之前纠正其保留。比视口高的块甚至会跳过这个。他们的过度保留隐藏在折叠之下，因此渲染不值得付费。观察者捕捉到其余的部分。某些高度变化不会移动指纹，也不会与滚动一致：输入回复编辑器、完成加载图像、切换 <details>。每个已安装的块都会保留一个ResizeObserver，但默认情况下它所做的只是标记该块，以便空闲通道重新读取它。它本身从不写入高度，这将关闭我们拒绝的反馈循环。它在卸载时断开连接，并且不活动的拉取请求选项卡观察不到任何内容。但有一个特意的例外。对于您自己造成的调整大小，等待显然是错误的：展开一个<details>，打开一个回复编辑器，一个图像登陆。该块立即增长，但其下面的代码仅在下一次空闲传递时移动。对于一帧，注释更高，而其下方的所有内容都位于原来的位置，您可以看到两个台阶。因此，当一个块安装在屏幕上时，观察者现在会测量它并在绘制之前在同一帧中应用校正。块变大，代码重新定位，下面的所有内容都会一起移动。有两个保护措施可以防止这种情况成为我们要避免的循环：每帧最多一次同步提交，因此一系列调整大小会折叠成一个，并且永远不会在活动滚动期间回落到批量传递。

The measurement scheduler, and the mistake we made first

This part took the longest to get right, because our first design was wrong in an instructive way.

The obvious way to measure dynamic content is one ResizeObserver per block, which watches the element and writes its measured height back into the layout whenever it changes. This is what we designed and then rejected during performance hardening. It is the feedback loop that big virtualized surfaces have to avoid. An observer that writes a height back into the layout of the element it’s watching can retrigger itself, and the cost grows with every mounted block.

What shipped instead is a single idle- and scroll-gated measurement pass, held to the same discipline as the deterministic side:

Off the hot path. It runs when the visible range settles, never once per scroll frame, and waits entirely while a scroll is in flight. A reflow mid-scroll is exactly the jank we’re avoiding. It runs again once scrolling stops. Scoped to the viewport. Only blocks within roughly 2400px of the viewport are candidates, so the work is O(viewport). Distant blocks keep riding their estimate and get corrected as they approach. On-screen reads win. A mounted block is on screen, so its rendered height is ground truth. The pass reads every mounted candidate in one batch, a single reflow with no writes in between, and records what it finds. A mounted block is never skipped in favor of a stale estimate. That one rule fixed the nastiest bug we hit: comments that rendered with a strip of blank space underneath, because a mounted block had been filtered out of measurement and left sitting on a too-tall estimate. Off-screen measurement is a bounded fallback. For a nearby block that hasn’t mounted yet, the pass does at most one off-screen render, to correct its reservation before it scrolls into view. Blocks taller than the viewport skip even that. Their over-reservation hides below the fold, so the render isn’t worth paying for. An observer catches the rest. Some height changes don’t move the fingerprint and don’t coincide with a scroll: typing in a reply composer, an image finishing loading, toggling a <details>. Each mounted block keeps aResizeObserver, but by default all it does is flag the block so the idle pass re-reads it. It never writes a height itself, which is what would close the feedback loop we rejected. It disconnects on unmount, and an inactive pull request tab observes nothing. With one deliberate exception. Waiting was visibly wrong for resizes you caused yourself: expanding a <details>, opening a reply composer, an image landing. The block grew immediately, but the code below it only moved on the next idle pass. For one frame the comment was taller while everything under it sat at its old position, and you could see the two steps. So when a block is mounted and on screen, the observer now measures it and applies the correction in the same frame, before paint. The block grows, the code repositions, and everything below shifts together. Two safeguards keep this from becoming the loop we were avoiding: at most one synchronous commit per frame, so a burst of resizes collapses into one, and never during an active scroll, where it falls back to the batched pass.

Put the loop on autopilot

The centerpiece was an autonomous change → measure → improve loop. Two lanes:

A headless probe lane ran a declarative flow (open a pull request, scroll to a fraction, toggle a details block, resize the window) against a mock server, reading the app’s own production instrumentation: React render counts, the performance timeline, and a requestAnimationFrame sampler for jank. It did the whole instrument, drive, collect, analyze, rank cycle by itself and printed the bottlenecks in order. Because the flow is just JSON handed to the probe at runtime, an agent could profile any flow by describing it in plain English, without editing a line of source.

An autopilot drove the actual desktop app through the huge-pull-request flow, unattended, on a loop: first cold, with comments still skeletons, then warm, with comments loaded, toggling <details> blocks, opening and cancelling reply composers, collapsing and expanding files, toggling the sidebar tree, sweeping deep into the file list, resizing the window. Every measurement was mirrored to the app’s on-disk log, so an agent could read runtime behavior with nobody at the keyboard. Each sample carried a health signal, and that was the objective check. A warm sample counted as healthy only if there were no unfilled gaps between comments, no comment blocks left blank, and real thread content actually mounted, across the entire scroll range, deep-file sweep included.

The loop we ran was:

Reproduce unattended, on the real engine. Arm the autopilot, let it loop, read the on-disk log. Detect with a health signal, not with your eyes. Trust the sample fields. Probe the suspect seam. When a signal goes bad, add one narrow structured probe there, re-arm, re-read. (Editing the surface hot-reloads the live window and re-arms the autopilot, so a fresh capture is about one cycle away.) Remove the scaffolding. Once you understand the invariant, pin it in a test and the design doc, and keep only the detector-grade signals.

中转查

在 GitHub Copilot 应用程序中呈现巨大的拉取请求

正文 · 来源原文

问题的范围

第 1 部分：虚拟化，以及为什么评论会破坏它

是什么让大差异变得更快

Rendering huge pull requests in the GitHub Copilot app

正文 · 来源原文

The scope of the problem

评论如何改变合同

两种几何形状而不是一种

测量调度程序，以及我们首先犯的错误

滚动锚定：在不与用户对抗的情况下进行纠正

第 2 部分：地表后面的管道

第 3 部分：测量循环，或者我们如何实际发现错误

使用应用程序的真实信号进行检测，而不是一次性日志

将循环置于自动驾驶状态

这给我们留下了什么

相关帖子

Part 1: Virtualization, and why comments break it

What makes big diffs fast

How comments change the contract

Two geometries instead of one

The measurement scheduler, and the mistake we made first

Scroll anchoring: Correcting without fighting the user

Part 2: The pipeline behind the surface

Part 3: The measurement loop, or how we actually found the bugs

Instrument with the app’s real signals, not throwaway logs

Put the loop on autopilot

Where this leaves us

Related posts