GitHub's New Pull Request Overview Page Enters Public Preview

GitHub has put a redesigned pull request Overview page into public preview as of November 5, 2026. The new page compresses the merge box, checks, comments and approvals into a single compact readiness summary at the top of the pull request, adds filters so reviewers can jump straight to unresolved conversations, and moves actions like marking a draft ready or closing a pull request into the page header. It's opt-in for now: anyone can try it from a button in the pull request header and switch back to the classic layout at any time during the preview.

What's actually new on the pull request page

The headline change is where GitHub puts the information reviewers need first. On the classic pull request Overview page, the merge box sits below the comment thread and conversation history, and it can take a fair amount of vertical space to show checks, required reviews and merge conflicts. In the new preview, that same information is condensed into what GitHub's changelog describes as "less than half the space" of the classic merge box, and it's pinned near the top of the page as a compact readiness summary.

That summary shows, at a glance, the pull request's checks, comments and approvals alongside the single next action a reviewer or author needs to take, such as updating a branch before it can merge. A second summary in the upper right of the page highlights review comments, review requests and other recent activity, so a reviewer returning to a pull request after a few hours doesn't have to scroll the whole timeline to see what changed.

Comments themselves get new filtering and sorting controls: a toggle between All, Unresolved and Mine, plus the option to sort newest first instead of the traditional chronological order. For a pull request that has accumulated dozens of comments across several review rounds, that's a meaningful change to how quickly a reviewer can find the threads that still need a response.

Finally, GitHub moved two actions that used to live further down the page into the header itself: marking a draft pull request ready for review, and closing a pull request, each gated by the same permissions as before. Those controls are now available as soon as the page loads, rather than after scrolling past the description and timeline.

None of this changes what a pull request is or how merging works under the hood. Branch protection rules, required status checks, required reviewers and merge queues all behave exactly as they did before; per GitHub's own documentation on pull request reviews, the Comment/Approve/Request changes decision flow and timeline-based tracking of feedback are unchanged — the preview only changes how that same information is laid out and how quickly a reviewer can act on it. GitHub has not said whether the new layout changes anything about the underlying pull request API or webhooks, and nothing in the changelog post suggests it does.

Part of a longer pull request redesign in 2026

The Overview preview doesn't arrive in isolation. GitHub has been reworking how pull requests are browsed and reviewed for most of 2026. In March, a new pull requests dashboard at github.com/pulls entered public preview with an inbox and saved views; by April that dashboard moved to an opt-out preview, meaning it became the default experience unless a user switched back. In September, GitHub shipped a refreshed repository-level pull request list in public preview, adding content-assisted filtering, AND/OR advanced search, a collapsible sidebar and a denser list view, though it still lacked milestones, bulk updates and saved custom views at launch.

The new Overview page is the next piece of that same effort, this time aimed at the single pull request view rather than the list of pull requests. Taken together, the changes point at a consistent goal: reduce how much scrolling and context-switching a reviewer has to do to understand where a pull request stands and what it needs next.

How to turn it on

There's no admin setting, organization policy or feature flag involved. Any pull request page shows a "✨ Try the Overview page" control in the header; selecting it swaps in the new layout for that session. The same menu offers a way back to the classic Overview page for as long as the feature stays in preview, so teams can test it without committing to it repository-wide. GitHub hasn't published a timeline for when the preview might become opt-out or generally available, following the same March-to-April pattern it used for the pull requests dashboard earlier this year.

What developers are saying so far

GitHub opened a feedback thread, Community Discussion #212186, alongside the announcement, framing the redesign as "the first step toward making pull requests easier to follow." The earliest substantive reply, from a developer identified as simon-abbott, welcomed the merge box moving to the top of the page but raised several concerns: newest-first as the default comment sort felt wrong for following a review from the start, the borderless pull request description looked visually out of place next to the rest of the page, and review-status icons were, in their view, too small to scan quickly.

The most pointed feedback concerned split timelines, which the commenter said hide force pushes and remove the direct link to a force push's diff — a workflow detail that matters more on pull requests that get rebased or force-pushed repeatedly during review. GitHub staff, including a product manager who replied in the thread, acknowledged the feedback and said the team would review it internally, and followed up by asking whether users care more about seeing the most recent force push or the full history of them. Other commenters flagged a contrast issue with a thin bar in light mode and asked whether a particular visual detail was a styling bug rather than intentional. It's the kind of granular, workflow-specific feedback that public previews are meant to surface before a change ships broadly.

Why pull request review UX matters more with AI in the loop

The timing lines up with a separate trend this site has covered repeatedly through 2026: a growing share of the pull requests developers review were at least partly written, or already reviewed once, by an AI coding assistant. VS Code's own Copilot Fusion rollout and the steady cadence of model changes inside GitHub Copilot are both part of the same shift: more code suggested or generated by an assistant means more pull requests, and more comments on those pull requests, for a human to triage.

GitHub's own data backs that up. On the same day as the Overview preview, GitHub also updated its Copilot usage metrics API to report a new "addressed rate" for Copilot's code review comments — the share of Copilot-authored review comments on a merged pull request that a developer actually acted on, whether by applying the suggestion directly, asking Copilot to make the fix, editing the code by hand, or saying a follow-up pull request would handle it. That metric, broken down by severity and review tier, exists specifically so organizations can measure whether an AI reviewer's comments are worth the noise they add to a pull request. A denser, filterable comment view is a reasonable complement to that: if a reviewer is now sorting through comments from both human colleagues and an AI reviewer, being able to filter to Unresolved or Mine, instead of scrolling a single chronological thread, saves real time. None of this is unique to GitHub's own Copilot, either — the same crowding shows up whenever any AI coding tool opens pull requests at a pace no human reviewer previously had to match, and it's one reason the status of the CI/CD checks that gate a pull request now gets top billing in the new readiness summary rather than being buried below the fold.

What it means for developers and teams

For an individual contributor, the immediate change is cosmetic but useful: less scrolling to find merge status, and a faster way to filter down to the comments that still need a reply. For a maintainer or lead reviewing many pull requests a day, the consolidated readiness summary and recent-activity panel are closer to what a pull request dashboard already provides at the list level, now brought down into the single pull request view.

Teams that rely heavily on force-pushing during review should read the community feedback before opting in broadly: the split-timeline behavior flagged in Discussion #212186 is a real workflow gap, not a cosmetic quibble, and GitHub has not yet said how or whether it will change it. Because the preview is opt-in and reversible per session, there's little risk in testing it on a few pull requests first, rather than switching an entire team over on day one.

It's also worth remembering that a per-session toggle, not an organization-wide switch, is what's on offer right now. Nothing in the changelog post mentions an enterprise or organization policy to force the new Overview page on or off for every member, which means two developers reviewing the same pull request could easily be looking at two different layouts of the same information. Teams that write internal documentation describing where to find merge status or how to filter comments may want to note that the screenshots in that documentation will look different depending on whether a given reviewer has opted into the preview, at least until GitHub settles on a single default.

What to watch next

Three things are worth tracking. First, whether GitHub addresses the force-push and timeline complaints raised in the feedback thread before any move toward opt-out or general availability — the dashboard preview earlier this year took roughly a month to go from public preview to opt-out default, so a similar cadence here would put a broader rollout in GitHub's near-term pipeline. Second, whether the Overview redesign eventually touches the Files Changed and Commits tabs, which GitHub has also refreshed separately in past changelog entries, to bring the whole pull request experience into one consistent design. Third, whether GitHub ties the new Copilot "addressed rate" metric into the Overview page itself, for example by surfacing how much of a pull request's outstanding comment count comes from an AI reviewer versus a human one. For now, the practical step for any developer who reviews pull requests on GitHub is simple: click "Try the Overview page" on a real pull request, decide whether the denser merge summary and comment filters fit a team's review habits, and leave feedback in the community discussion if something breaks a workflow the classic page supported.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage