GitHub New pull request overview page in public preview
196 points
• 4 days ago
• Article
Link
管理长篇 Pull Request 往往会变成一种令人沮丧的"向下滚动"体验：开发人员需要在大量评论和时间线事件中来回穿梭，才能找到合并框（Merge box）。好不容易到达之后，接下来该做什么才能继续推进，仍可能让人难以判断。为此，我们正在推出一个全新的概览页（Overview page）作为可选的公开预览，通过在页面顶部以精简摘要形式突出关键的合并状态（Merge status）和可操作事项（Actionable items），从而简化整体流程。
本次更新的核心是精简版的合并框（distilled merge box）。它经过重新设计，占用空间不到经典版本的一半，同时保留必要信息。通过将 Checks 、 Comments 和 Approvals 等关键信号集中呈现，新布局让用户能更快判断合并是否已就绪（merge readiness）。如果某个 Pull request 被阻塞，用户也能在这个汇总视图中清楚看到所需操作，例如更新分支（update a branch）。
在合并框之外，新概览页还提供了更好用的进度跟踪与专注工具。用户现在可以筛选未解决的对话（unresolved conversations）或自己的评论（their own comments），从而迅速找出仍悬而未决的问题。此外，支持将评论按"最新到最旧"排序，帮助开发人员第一时间追上最新反馈；右上角的活动摘要（activity summary）还能快速查看近期更新，例如评审请求（review requests）。
想要体验新界面的用户可以在页头（header）中选择对应选项进行启用，并可随时切回经典视图（classic view）。该预览只是起点，我们也非常欢迎大家提出反馈，以帮助塑造未来更完善的 Pull request 体验。用户可以通过专门的社区反馈讨论（community feedback discussion）分享想法或反馈问题，确保最终落地的功能真正符合开发人员的需求。
Managing long pull requests often becomes a frustrating exercise in scrolling, as developers must navigate past numerous comments and timeline events just to reach the merge box. Once they finally arrive, it can still be difficult to decipher the next steps required to move forward. To address this, a new overview page is being introduced as an opt-in public preview, designed to streamline the experience by surfacing critical merge status and actionable items in a compact summary at the top of the page.
The core of this update is the distilled merge box, which has been redesigned to occupy less than half the space of the classic version while retaining essential information. By centralizing supporting signals like checks, comments, and approvals, the new layout allows users to quickly assess merge readiness. If a pull request is blocked, users can clearly see the necessary actions, such as updating a branch, directly within this consolidated view.
Beyond the merge box, the new overview page offers improved tools for tracking progress and staying focused. Users can now filter for unresolved conversations or their own comments to quickly identify open questions. Additionally, the ability to sort comments from newest to oldest helps developers catch up on the latest feedback immediately, while an upper-right activity summary provides a quick look at recent updates like review requests.
Those interested in testing the new interface can activate it by selecting the option in the header, with the ability to revert to the classic view at any time. This preview serves as a starting point, and feedback is actively encouraged to help shape the future of the pull request experience. Users can share their thoughts or report issues through the dedicated community feedback discussion, ensuring the final implementation aligns with developer needs.
129 comments • Comments Link
- 以 Pull Request 为中心的工作流程正变得难以扩展，因为由 LLMs 驱动的自动化代码生成显著增加了变更数量与复杂度，致使人类审查员难以真正完成审计工作。
- 代码审查正日益被视为低效且支离破碎的把关环节。一些人主张团队应转向架构：要么代码默认被信任，要么由系统性不变量（systemic invariants）来管理，而不是依赖人工检查。
- GitHub 平台的批评者认为，频繁的 UI 更新和"臃肿"的功能掩盖了核心产品故障，例如加载缓慢、状态检查不可靠，以及让日常工作更加复杂的 inbox 体验退化。
- 审查员很难适应 AI 生成的代码。尽管这些代码在语法上无懈可击，却可能在语义层面毫无意义，从而破坏了依赖启发式判断来发现错误或架构缺陷的传统方法。
- 现代开发需要新的工具范式，例如"semantic diffs"。它更重视结构与意图（如重命名或移动的代码块），而非原始文本差异，并支持非线性的、按任务组织的代码导航。
- 许多团队正在转向外部 merge queues 和第三方仪表板工具（如 Graphite），以替代 GitHub 的原生界面。他们认为这些方案在组织性、原子合并能力（atomic merge）以及信息密度方面更占优势。
- 对 LLMs 的依赖带来一种错位：部分开发人员用 AI 生成大量变更，而另一些人则试图进行细致的人工审查，进而在团队内部引发摩擦与挫败。
- 普遍的看法是，GitHub 已经不再把稳定性与性能放在核心位置。用户对那些看起来像是由正在破坏其审查流程的 AI 工具撰写的营销文案感到不满。
- 对未来开发的建议包括"agent-only"流水线：在尽可能少的人工干预下，将人工监督聚焦在系统设计层面，而非逐行审查层面。
- 一些看似简单的改进——例如控制文件顺序、跟踪已查看的代码块（hunks）以及在提交之间保持稳定状态——仍远未满足需求，目前反而迫使开发人员采用低效的人工权宜之计。
此次讨论反映了开发人员深层的挫败感：他们认为，在 AI 驱动的开发速度压力下，传统的 pull request 模型正在失灵。大多数参与者基本认同，GitHub 对表面 UI 更新的投入并未解决平台稳定性退化，以及"机器生成代码"这一新现实带来的审查挑战。尽管有人主张从"人在回路"（human-in-the-loop）根本性转向让自动化架构来强制执行，但也有人继续尝试使用能更好呈现代码意图的第三方工具。最终形成的共识是：现状不可持续，因此开发人员不得不在混乱的"快速发布"文化与构建自定义、可更易管理的流水线之间做出选择。 • The current Pull Request-centric workflow is failing to scale, as automated code generation from LLMs has dramatically increased the volume and complexity of changes that human reviewers can no longer feasibly audit.
• Code review is increasingly viewed as an inefficient, broken gatekeeping process, with some arguing that teams should move toward architectures where code is either trusted by default or governed by systemic invariants rather than manual inspection.
• Critics of GitHub's platform suggest that frequent UI updates and "bloated" features mask core product failures, such as slow load times, unreliable status checks, and a degraded "inbox" experience that complicates daily work.
• Reviewers are struggling to adapt to AI-authored code, which can be syntactically perfect but semantically nonsensical, breaking traditional heuristics for identifying bugs or architectural flaws.
• Modern development requires new tooling paradigms like "semantic diffs," which prioritize structure and intent (such as renames or moved blocks) over raw text changes, and allow for non-linear, task-based navigation of code.
• Many teams are turning to external merge queues and third-party dashboard tools like Graphite to replace GitHub's native interface, citing better organization, atomic merge capabilities, and superior information density.
• The reliance on LLMs has created a misalignment where some developers use AI to generate massive changes while others attempt to perform meticulous, manual reviews, leading to team-wide friction and frustration.
• There is a pervasive sentiment that GitHub has lost its focus on stability and performance, with users expressing irritation at marketing prose that feels generated by the very AI tools currently destabilizing their review workflows.
• Proposals for the future of development include "agent-only" pipelines with minimal human intervention, focusing human oversight at the system design level rather than the line-by-line review level.
• Simple improvements, such as controlling the order of files, tracking viewed hunks, and maintaining stable state across commits, remain unmet needs that currently force developers to resort to inefficient, manual workarounds.
The discussion reflects a deep sense of frustration among developers who feel that the traditional pull request model is buckling under the pressure of AI-driven velocity. Participants largely agree that GitHub's focus on superficial UI updates fails to address the underlying degradation of platform stability and the new reality of reviewing machine-generated code. While some argue for a fundamental move away from human-in-the-loop review toward automated architectural enforcement, others continue to experiment with third-party tools that better visualize code intent. Ultimately, the consensus is that the status quo is unsustainable, leaving developers to choose between chaotic "ship-fast" cultures or building their own custom, more manageable pipelines.