Improved pull request "Files Changed" experience feedback

[Akash1134]

About the new experience

This updated experience focuses on performance, accessibility, and user productivity. Read more in the changelog.

Tip

If you are not already using the new experience, click the ✨Try the new experience in the upper-right corner of the classic "Files changed" page. You can easily switch back from the Preview menu.

✨ What's new

If you are coming from the classic experience, the new experience should feel familiar but adds some significant improvements:

• Comment on any line: You can now comment on any line of a changed file, not just the lines surrounding a change.
• View the description without switching pages: You can now view the pull request description from the new Overview panel on the "Files changed" page.
• Reviewing made easier
  • Enhanced file tree: The file tree is now resizable with indicators showing the files with comments, errors, and warnings.
  • Review your pending comments: Pending comments are now shown in the review submission panel, so you can double-check your feedback before submitting.
  • Draft comments: New comments and replies are saved locally so you won't lose them if you accidentally close your browser or refresh the page.
• Fewer page reloads: Clicking Refresh to pull in new changes, switching between split and unified modes, and other tasks will no longer force a full page refresh.
• Accessibility & readability: Keyboard navigation, screen reader landmarks, and increased line spacing options are now available to make the experience available to everyone.

✨ Updates

See what's been fixed and improved since the launch of the public preview:

• June 26: initial changelog
• July 17: file-level commenting, performance fixes, diff loading and expansion issues, and more
• July 31: rich diff support, improve file tree ordering, and more
• August 21: improved review submission panel usability, submodule support, and lots of fixes
• September 11: temporary single file view to improve scale (see message above)
• September 25: commenting on unchanged lines 🎉 , single file mode improvements, and more
• November 6: apply suggested changes in a batch, collapsible annotations, and more
• November 20: new Overview panel (for viewing PR description), performance and other fixes
• December 11: review by commit, improved commit filtering, filtering improvements, and more
• January 23, 2026: default experience for all users, new experimental mode that uses virtualization to support larger pull requests (up to 3,000 files)
• February 5, 2026: CODEOWNERS validation support added, additional performance improvements

🟡 Limitations

As of the initial public preview release, there are some temporary limitations that will be addressed over time:

• Annotations on unchanged files
• Small screen (e.g. mobile device) responsive layout

While our previous experience had hard limits on large PRs, this new experience is being built to scale. That said, we’re increasing our limits incrementally. To start with, our additional current limitations are:

• Limited to 1,000 files in single file mode or 3,000 in experimental mode
• Comments: 40 in the page (but up to 350 in the Comments side panel)
• Replies per comment: 20
• Alerts: 50

How you can help

1. Report bugs, edge cases, or usability pain points in the replies (screenshots/gifs welcome).
2. Tell us which future enhancements would make the biggest impact on your workflow.

Thanks for helping us build a better review experience—we read every comment!

[willmarcondeseso]

I would like to be able to scroll through the Pull Request while the comment modal is open.

Reason: When a comment is outdated, we need to look at the current version to check if it actually addresses the comment.

I really love this feature! THANK YOU!!!

[wey05]

❤️

[Tycho-Green]

The button to "go to where this comment is" is a no-op.

[alles60]

Came to ask this as well. There is a panel for comments, but when you click to go to the relevant line, it shows the previous section, not the new section. Thus, it's not easy to see if the requested change was actually applied.

[rtalexk]

Update: I just found out that it appears when there's enough space (1280px width). Here's the updated feedback.

I'd like to see the branch name in the sticky header at all times so that I can easily copy it when I'm reviewing a PR.

---

I wrote the following before thoroughly experimenting.

I'd like to see the branch name when the sticky header is shown (i.e., when you've scrolled to the bottom).

The reason is that when I'm reviewing a long PR and want to checkout the branch to continue reviewing it locally, I have to go back all the way up to see or copy the branch name and then go back to where I left off.

[pakeeza2425]

I know exactly what you mean — the old sticky bar made it so much quicker to jump back to the Conversation tab. Right now the extra scrolling or focus-shifting adds friction, especially during long reviews. A persistent header or sticky navigation with the tabs always visible would be a nice quality-of-life improvement. Not critical, but definitely one of those small things that would make the workflow feel smoother.

[duduedufsa]

This update focuses on three essential pillars of a modern code review experience: performance, UX, and accessibility.

Optimized diff rendering with reduced memory consumption.

[Endy0611]

This update focuses on three essential pillars of a modern code review experience:
performance, user experience, and accessibility.

We’ve optimized diff rendering to significantly reduce memory consumption,
resulting in faster load times and smoother navigation when reviewing large
pull requests.

[vivoysg372-source]

Default auto goto V2344

[rtalexk]

I find the comment indicators in the sidebar really useful. It might also be useful to have them in the "diff file header."

It's very useful when you've marked a file as "viewed" because you can see how many comments it has as you're scrolling without having to expand it.

[eengelhardt]

this is happening for me too.

Some comments are showing up in file and some are not

[xiangsgao]

where is the copilot here?

[v-coder247]

Hi @mohamedmagdysayed2040-prog, thanks for participating!

Unfortunately, we don’t currently have moderators for languages other than English. Until that changes, we need to ask that everyone use English here in the GitHub Community when posting to ensure discussions are adhering to our Code of Conduct.

We’ll be locking this post for now, but please feel encouraged to create a new discussion in English if you still need support.

[error-reporting]

https://github.com/orgs/community/discussions/163932#discussioncomment-18393017

[rtalexk]

Seamlessly switch between split and unified views.

This is really cool. Is it also possible to seamlessly toggle hiding white spaces? If that's achievable without doing a refresh would be amazing.

[mustmodify]

remembering per-user and per-PR seems both obvious and would result in a significantly better experience.

[ericgreveson]

Thanks for the feedback.

• We are planning to support seamless switching of "hide whitespace-only changes", but no timeline yet.
• We are also exploring the implications of making this a user-level preference so it would be remembered/applied consistently across all PRs. Do others have thoughts/opinions on this?

Would it be possible to set "Compact line height" as a user preference as well? I like the changes overall but much prefer the original setting.

"Hide whitespace-only changes" as a user-pref sounds good.
Regarding line spacing, currently, compact mode is an option but the default is to be "extra line height". I feel like "Compact line height" should be the default (to match the current experience, but also because the greater code density from compact mode is in my opinion likely to be more useful to more people when reviewing, compared to the accessibility-focused greater spacing).

[msmygit]

Peer review comments are now very hard to find and finally after an hour of searching around I found the 💬 icon and when I clicked on the reply, it just barfed and took me to the Files Changed view without showing the review comments or their replies.

[hackel]

Thanks for the feedback.

* We are planning to support seamless switching of "hide whitespace-only changes", but no timeline yet.

* We are also exploring the implications of making this a user-level preference so it would be remembered/applied consistently across all PRs. **Do others have thoughts/opinions on this?**

I don't suppose you have any update on this yet, do you? It's really tedious to have to remember to:

1. figure out which button reveals the menu
2. click the button
3. click the menu item
4. wait for the page to reload

Every Single Time I open a PR. Call me crazy, but it seems like there are an extremely small number of cases where one might not want this feature enabled by default. The mechanics of the feature itself seem so trivial, I'm sure Copilot could crank it out in 5 minutes. I hope to see some traction on this soon!

[rtalexk]

Clicking a line number always assumes you want to add a comment.

In the previous experience it only changes the URL to have deep linking.

[aaccioly]

Any workarounds to obtain permanent urls?

[arisacoba]

@rtalexk which browser are you using? Clicking the line number should just highlight the line, not open the add comment flow.

[rtalexk]

I'm using Arc Browser, but this isn't happening anymore. 👀

[astroanu]

It seems the comment urls are not working on the new experience if the PR is really big. The old UI still navigates to the comment correctly.

[thuringia]

This is so much better, I might go back from reviewing with the VSCode extension now 🚀

I love the new alerts panel, unfortunately it looks like pressing a to hide them doesn't work anymore.

Maybe we could have some grouping or clustering in the alerts panel in the future.
For example I would prefer to see alerts raised by the linter first, instead of "this line is not covered by tests".

[audreyality]

unfortunately it looks like pressing a to hide them doesn't work anymore.

When this feature comes back, it'd be nice if hiding the annotations also stopped them from being added to the clipboard when copying code.

[willsmythe]

Thanks for the feedback. We are planning to restore the ability to use a to hide annotations.

[mccrearyp]

@willsmythe any update on when this is getting added?

[jsync-swirlds]

In addition to using a to hide annotations, can we have a global (user) setting to hide annotations by default?
Having to tap a (which does not always work correctly, particularly for large diffs) for every PR in repos that overuse annotations (a distressingly common practice that makes review a painful chore) is irritating and we're still left with (often) dozens of files that now have no visible change because some irrelevant annotation happened to touch that unchanged file.

[mccrearyp]

Are you not planning on adding this feature back anymore? Did you forget about it? Do you need help? If you need the code here is what I was able to do to add this feature from my browser console:

document.addEventListener('keydown', (e) => {
  if (e.key === 'a' || e.key === 'A') {
    document.querySelectorAll('.InlineMarkers-module__markersWrapper--Fw1hl').forEach(el => {
      el.style.display = el.style.display === 'none' ? '' : 'none';
    });
  }
});

[reecefenwick]

I would love to see the file tree sorted alphabetically with folders on top, then files. It is quite jarring to have changed files in the middle of folders when viewing the file tree currently.

Example of current state

App.tsx
components/
hooks/
index.ts
styles/
utils.ts

Example of desired state

components/
hooks/
styles/
App.tsx
index.ts
utils.ts

This would mirror how the majority of developers view the code in their IDE

[franzliedke]

Indeed, files below would also be consistent with GitHub's own repo tree view.

[warp10]

I see the value in being consistent with the repo’s tree view; nevertheless, having files listed first can have some interesting use cases. For example, if a PR includes a changelog file or a “manifest,” listing files first would make it one of the first (often the very first) files shown, which I think is nice when reviewing code. In my opinion, that would greatly help the review process. Just my two cents.

[parasyte]

I recommend sorting the same way as git diff-tree, which is what I think the old view did.

$ git diff-tree -r ..main
:100644 100644 d68e1befa16c82c562359a15a283a838d72b0727 e24eac8e828629741b34632e9ef2493a9a95d753 M      src/cryptosuite.rs
:000000 100644 0000000000000000000000000000000000000000 9ad4b1337b54bf28686cf4becccac13124fe6747 A      src/cryptosuite/bip340_jcs.rs
:000000 100644 0000000000000000000000000000000000000000 ab474845d58506540e0ac7e6f0e287770efa1b41 A      src/cryptosuite/bip340_rdfc.rs
:000000 100644 0000000000000000000000000000000000000000 92337d2e16e7ec1f1d2ebc0836773c2099538a1d A      src/cryptosuite/transformation.rs
:000000 100644 0000000000000000000000000000000000000000 fa9ba63738d7b46f5f4647deb01328f6b6981777 A      src/cryptosuite/utils.rs
:100644 100644 f016785749ea50aeb255c80d1a08c1f53b108f6e cd40229a1055c0bd102c6f47318b0d874ab83610 M      src/document.rs
:100644 100644 8b798f1b9f21f3699cdd399939664e9ef4744a8d e2de154c3a730a5b055d6e944e0b8adb98e26f57 M      src/update.rs
:100644 100644 8c80fd426222a68987e2938d37549005bc9db2a0 9c98405bb3803c789dd49a23ca291f2fd9b774cd M      src/zcap/proof.rs

Old view:

New view:

[richard-rance]

Most tools put the folders first but I wish the standard was files first.

The files in a folder typically describe its contents. For example READMEs, Changelogs, manifests, public functions/interfaces. The sub folders contain the implementation details. I would like to read those first when reviewing a PR (or writing code).

That lets me see if their description makes sense to someone who does not know the internal implementation details. Then I can drill into the sub folders that contain the described implementation to see if they match.

It also helps for languages, like golang, that have a vendor folder containing a copy of all dependencies. It would end up at the end of the PR which is perfect since I basically ignore it when doing a review. Right now I have to scroll past all the vendor files to get to the top level files. That can lead to them being missed.

[sethrh]

This would mirror how the majority of developers view the code in their IDE

[Citation needed.]

I'd prefer the ordering stay the way it was. But developers are an opinionated bunch, so if this is going to change there should be a way to set preferences. Besides, there are also other options besides just alphabetical and alphabetical by folder that might be useful, such as eliminating the tree view altogether and just showing file paths or even just file names.

[Nilomiranda]

I don't see the option to comment on the file itself, only on specific lines.

Some files just get stuck into a loading state, like this one:

The comments tab is really nice, I like being able to filter comments by author, makes it much easier to navigate the reviews and attend to the requested changes or overall feedback.

[iifeiss780-wq]

App.tsx

components/
hooks/
index.ts
styles/
utils.ts

[ia0-review]

Should there be a separate thread for the "loading state" issue? I'm afraid this might be buried because the "comment on file" issue has been fixed.

[adcoelho]

This is still happening for me when selecting "Files owned by me". They don't load, and I am unable to review. Any known workaround?

[glureau]

Workaround I've just found, go back to old experience, then load again the new experience.

[shirmetomotion]

I like being able to filter comments by author, makes it much easier to navigate the reviews and attend to the requested changes or overall feedback.
I would love that too! But it currently doesn't work :(
The filter does nothing

[jieyouxu]

Hi, I would like to play around with this, but I'm not seeing the opt-in mentioned in

You can opt in to the public preview from any pull request via “✨Try the new experience” in the upper-right corner. You can return to the classic view by clicking the “switch back” link.

Am I missing something?

[imanmahjoubi]

We are rolling this out to users slowly, you should be able to see it soon 🎉

[margaret-lin]

The tab for Ask Copilot seems to be missing, also when hovering over lines.

[rr-jimmy-multani]

I'd prefer that this button stay since it's related to the PR and its changes.

[daira]

Feature request: allow people who object to AI (and there are many of us) to turn it off, completely, without the risk of accidentally using it by some misclick or dark pattern.

[3nprob]

Bug: This button is visible even if Copilot is fully disabled in user settings.

[Biglulux]

Asking Copilot to summarize the PR is important to my workflow, so I would like the Ask Copilot button to return to the Files Changed page as well. An alternative could be allowing non-main branch files to be attached to regular Copilot chat, since currently only files on the main branch for all repos can be attached.

[kanonji]

Because my team is understaffed, I often have to review PRs that use languages, frameworks, or libraries I am not very familiar with.
For that reason, I rely heavily on "Ask Copilot about this file-diff" (the line-level Copilot actions).
Even if I can understand the overall design and structure, I do not know the fine-grained syntax or how specific library methods behave.

With the current "Files Changed" view, I can use "Ask Copilot about this file-diff" right away, but in the new view it takes 3 clicks.
If I use it 10 times in a single PR, that is 10 clicks vs. 30 clicks.
If I review 10 PRs, that becomes 100 clicks vs. 300 clicks.

For me, the version where I can use "Ask Copilot about this file-diff" with a single click is clearly better.

[njvrzm]

Not sure if this is the sort of feedback you're after, but the :shipit: emoji does not preview in the review textbox in the new version 😅 . It does show up correctly in the preview.

[willsmythe]

Thanks for the feedback. We'll address.

[cmargonis]

On the topic of emojis, I really liked that I could type e.g. :idea and it would suggest the 💡 emoji. It would be great if this functionality were preserved (or even expanded upon 🙏 )

[KeithYeh]

1. I can't find "comment on this file" button in new UI

Old UI

2. How to hide alerts? I can toggle alerts by pressing "A" in old UI

[willsmythe]

Thanks for the feedback. Both are known issues we're tracking.

[airvision-tw]

Indeed! I am also missing this functionality in the new view.

[cristinadoroftei]

True, I use the "comment on this file" feature quite often and I switched to the old view just because it's missing on the new one 😿

[Smolyan91]

+

[xmfcx]

How to hide alerts? I can toggle alerts by pressing "A" in old UI

This is very important for me.

[julioag-rmd]

On the Files changed tab I can only see 19 files out of 66. Why?

[ExtAnimal]

I'm only seeing ONE.

One at a time. I have to open the directory sidebar and click on each file or click the next/prev file buttons.

Whoever did this should be fired.

[bashar-qassis]

to be fair, they are showing an explicit notice, so it seems rather intentional

[tatosjb]

to be fair, they are showing an explicit notice, so it seems rather intentional

In that case they should fire who made this decision

[seriouslysean]

I agree with some of the previous comments. Seeing one file at a time is untenable when doing PR, I really need the option to see them all and scroll through for a seamless experience. There are many cases where a couple files may be related and it's useful to see them and flit between them.

[error-reporting]

on mobile GitHub ui there isn't even a previous and next button to move between the previous and the next file

[vengut]

I used to be able to click on a useful link to see the submodule diff in PRs but now its just plain text.
Old:

New:

Could we have that back pls?

[cdunford]

👍 any of the above; missing being able to see what changed; I have to flip back to do the old experience to do it

[Lachy-Antero]

Our release process heavily relies on the ability to click through to see the commit diff of submodules. Will be very sad to see this go.

[hsl0]

I want to see that nice summary of changes for non-GitHub hosted submodules, too.

[jlc6]

I would like to be able to see which commit I’m starting from and which one I’m going to in the changed submodules, as the old interface used to show.

[AminHeidaridahoee]

I also want to see the submodule commitId change in the file preview, it is necessary for our code review

[BE-Code]

It doesn't always seem to remember if hide whitespace was turned on.

[shahmir-oscilar]

I believe i was able to reproduce this. See steps at: https://github.com/orgs/community/discussions/163932#discussioncomment-13915305

[FeBe95]

Related: https://github.com/orgs/community/discussions/163932#discussioncomment-14012281

[warwick-kiwibank]

A certain order of the URL parameters triggers this bug. This works:
.../files?w=1&file-filters%5B%5D=.yml&file-filters%5B%5D=.tf

But if I put the hide-whitespace parameter after the file-filter parameters, it doesn't work:
.../files?file-filters%5B%5D=.yml&file-filters%5B%5D=.tf&w=1

The parameters are added to the URL in the order of selecting the options in the GUI. So, to avoid the bug, you need to show/hide whitespace, then apply file filters.

The old UI works as expected.

[Bangkah]

Same issue here on Win 11 + Edge 124. Worked after disabling “XYZ” flag. Thanks for the workaround!

[michaelphilipes]

It's amazing Solution that actually works. I applied the same solution on the Nawaz Sharif It city and results start coming.

[jpetot]

Bug: triple-clicking a line scrolls the page back to the top (new Files changed experience)

What happens
In the new "Files changed" view (Preview), triple-clicking a line of code to select it makes the page jump straight back to the top. I lose my place in the diff every time, which makes reviewing long PRs painful.

Steps to reproduce

1. Open a PR with several changed files in the new Files changed experience.
2. Scroll down into a file, e.g. around line 800+.
3. Triple-click a line to select its text.

Expected
The line's text is selected and the scroll position stays where it is.

Actual
The page immediately scrolls back to the top. Sometimes the inline comment box also opens on a line near the top.

Workaround
Opting out of the preview fixes it.

Environment

• macOS, firefox (latest - Version 158.0)

[mpiggott]

Adjacent complaint.

In browsers and in many other applications double-clicking a word selects it. Recent changes in Github PR view breaks this behaviour.

Additionally using click & drag to highlight text has also become flaky and Github's yellow highlight is overriding the selection highlight so when it is working its impossible to see what was actually selected.

[swarren-tp]

I really only have the two following requests

1. The ability to mark entire folders of files as viewed. Useful for things like folders of generated files that you have no interest in reviewing manually
2. The ability to focus an entire file, that is, click on a file and only have that file occupy the window. Currently it will "focus" the file but you can still scroll around to see other files; I just want to see the one file I picked (and have the entire file expanded)

[MelvinGrootCRX]

I really want the same:
https://github.com/orgs/community/discussions/163932#discussioncomment-18714641

[bew]

Bad UX: submitting a PR-level comment from the Files changed tab throws me onto the Conversation tab.

1. Open a PR, on the Files changed page.
2. Open the Comments side panel.
3. Type into the comment input at the bottom of the panel — this posts a PR discussion comment, not a review comment.
4. Submit.

Observed: I land on /pull/<n>, the Conversation tab.
Expected: I stay on /pull/<n>/changes, at the file and scroll position I was on.

I use that box mid-review, for thoughts that don't belong to a specific line.
Getting teleported away costs me my place in the diff and in the file tree, and I have to navigate back before I can pick the review up again.

If the side panel exists so a review can happen on one page, posting from it shouldn't move me to another one.

Comment drafted & iterated on with AI assistance

[bew]

I wanted to leave a review comment on a folder, and there's no way to do it 🤔
For comments like "this module should be split", "these files belong in another package", "this directory shouldn't be in this PR at all".

Line and file comments are the wrong scope for me, and a PR-level comment isn't a review comment (cannot be resolved).

As a workaround I comment on the first file of the directory instead, but if that file is expected to move, be renamed, or deleted, the comment is easily lost 😬.
Other possible workarounds:

• PR-level comment, but it's not attached to anything then and it can't be "resolved", and forces me out of the pending review (see https://github.com/orgs/community/discussions/163932#discussioncomment-19143602).
• Draft it in the review submission box but do not submit is similar, with similar downsides + a page reload or a browser crash can lose my comment ><

👉 What I'd be after is a folder-level comment behaving like a file-level one: resolvable, attached to the review, listed with the others.

👉 Same missing gap one level up: I'd like to be able to post comments attached to the review but not a specific file/folder, that I can resolve later.
As far as I can tell that doesn't exist 🤔.

Comment drafted & iterated on with AI assistance

[CraigMacomber]

The side panel UI provides no way to unresolve a comment thread. Also when I copy a link to one (which is also outdated, that might batter), navigating to that link doesn't work.

Edit: Oh, I see now, I need to Ignore where is says "resolved", and not look in any of the normal places GitHub UI puts options like that (buttons with descriptive text at the bottom of the thread), and click the little purple checkmark that's in the heading of the code excerpt that the commit thread is inside of. I think that UI design choice is unintuitive, though compact.

[michcio1234]

File type filter popup should stay open after clicking on one of the file types. I want to view just a single file type, so I need to uncheck all the others. It's hard to do it now, because the popup disappears after every uncheck.

[n8v-guy]

A few comments here ask for ways to cut a big PR down, like marking whole folders of generated files as viewed. Until something like that ships natively, I built a small open-source Chrome extension that adds it on top of the new Files changed page.

Files marked linguist-generated in .gitattributes start hidden and are viewed automatically. Every folder in the file tree gets a viewed badge, and one click on it marks the folder's unread files viewed.

Disclosure: I'm the developer; MIT, no token or account, collects no data: https://github.com/n8v-guy/diffseek

[n8v-guy]

For anyone who wants to try it, it's on the Chrome Web Store: https://chromewebstore.google.com/detail/lpohfkpkmaakdllgpognpjegifccnfec

[phillw1994]

Some Characters were displaying correctly in the classic experience but in this one they show as diamond question marks. Not sure if it is a ASCII vs UTF-8 issues. I cannot show code due to privacy as it is a private repo. The files in the repo are Windows 1252 encoded containing UTF-8 chars. The old experience shows them correctly. This one does not.

[himkt]

I really love the new sidebar experience—thank you so much for your work! One minor suggestion: the sidebar should be independently scrollable. Currently, its scrolling seems to depend on the main content, so I can’t scroll up (to see the search bar) in the sidebar without first scrolling up the main content.

[billy-cottrell]

Adding a proposal to further improve the diff viewer:

I personally find it annoying when you have this heap of text marked as changed but the change is so small you barely see it as it highlights the full line. This should allow to easier see the actual change instead of having to compare the full block of text and potentionally missing the actual change or perhaps even mistakes that might slip through.

The example above is ofcourse in unified view but could work in split view aswell and I just think only highlighting whats actually different will make things much easier to review not just for users but also for AI.

[SuperflyJon]

Highlight the currently displayed file in the file tree
When reviewing a PR, could the file tree on the left visually indicate which file is currently being displayed, for example by highlighting the filename?
With a large PR it's very easy to lose track of where you are in the file tree, particularly when navigating or scrolling between files. Having the tree selection follow the currently displayed file would make it much easier to maintain context.

[joestringer]

I would love to see a return of the UI buttons for browsing from one commit to the next. With the new UI it's awkward to understand a simple way to view one commit and then go to the next commit.

According to this comment, you can browse between commits using keyboard shortcuts. This is great and should be kept, but it's not very discoverable to learn about how to navigate between commits this way.

[ROBERT047]

O novém zážitku

Tato aktualizovaná verze se zaměřuje na výkon, přístupnost a produktivitu uživatelů. Více informací naleznete v seznamu změn .

Tip

Pokud nové prostředí ještě nepoužíváte, klikněte na tlačítko ✨Vyzkoušet nové prostředí v pravém horním rohu klasické stránky „Změněné soubory“. Zpět se můžete snadno přepnout z nabídky Náhled .

✨ Co je nového

Pokud přecházíte z klasického rozhraní, nové rozhraní by vám mělo být povědomé, ale přináší i několik významných vylepšení:

• Komentář k libovolnému řádku: Nyní můžete komentovat libovolný řádek změněného souboru , nejen řádky kolem změny.

• Zobrazení popisu bez přepínání stránek: Popis žádosti o změny nyní můžete zobrazit v novém panelu Přehled na stránce „Změněné soubory“.

• Snadnější recenzování

  • Vylepšený strom souborů: Strom souborů je nyní měnitelně velký a zobrazuje indikátory zobrazující soubory s komentáři, chybami a varováními.
  • Zkontrolujte čekající komentáře: Nevyřízené komentáře se nyní zobrazují v panelu pro odeslání recenze, takže si můžete před odesláním zpětnou vazbu znovu zkontrolovat.
  • Koncepty komentářů: Nové komentáře a odpovědi se ukládají lokálně, takže o ně nepřijdete, pokud omylem zavřete prohlížeč nebo obnovíte stránku.

• Méně opětovného načítání stránek: Kliknutím na tlačítko Obnovit se zobrazí nové změny, přepínáním mezi rozděleným a sjednoceným režimem a dalšími úkoly se již nevyžaduje úplné obnovení stránky.

• Přístupnost a čitelnost: Navigace pomocí klávesnice, orientační body čtečky obrazovky a větší možnosti řádkování jsou nyní k dispozici, aby byl zážitek dostupný pro všechny.

✨ Aktualizace

Podívejte se, co bylo opraveno a vylepšeno od spuštění veřejné verze Preview:

• 26. června : počáteční seznam změn
• 17. července : komentáře na úrovni souborů, opravy výkonu, problémy s načítáním a rozšiřováním rozdílů a další
• 31. července : bohatá podpora pro diff, vylepšené řazení stromové struktury souborů a další
• 21. srpna : vylepšená použitelnost panelu pro odesílání recenzí, podpora submodulů a spousta oprav
• 11. září : dočasné zobrazení jednoho souboru pro zlepšení měřítka (viz výše uvedená zpráva)
• 25. září : komentování nezměněných řádků 🎉, vylepšení režimu jednoho souboru a další
• 6. listopadu : dávkové použití navrhovaných změn, sbalitelné anotace a další
• 20. listopadu : nový panel Přehled (pro zobrazení popisu PR), výkon a další opravy
• 11. prosince : revize podle commitu, vylepšené filtrování commitu, vylepšení filtrování a další
• 23. ledna 2026 : výchozí prostředí pro všechny uživatele, nový experimentální režim, který využívá virtualizaci k podpoře větších požadavků na stažení (až 3 000 souborů)
• 5. února 2026 : Přidána podpora validace CODEOWNERS, další vylepšení výkonu

🟡 Omezení

Od prvního vydání Public Preview existují určitá dočasná omezení , která budou postupně vyřešena:

• Anotace u nezměněných souborů
• Responzivní rozvržení pro malé obrazovky (např. mobilní zařízení)

Zatímco naše předchozí zkušenost měla pro velké PR přísná omezení, tato nová zkušenost je vyvíjena s ohledem na škálovatelnost. Nicméně naše limity postupně zvyšujeme. Pro začátek jsou naše další aktuální omezení:

• Omezeno na 1 000 souborů v režimu jednoho souboru nebo 3 000 v experimentálním režimu
• Komentáře: 40 na stránce (ale až 350 v bočním panelu Komentáře)
• Odpovědí na komentář: 20
• Upozornění: 50

Jak můžete pomoci

1. V odpovědích nahlaste chyby, hraniční případy nebo problematické body použitelnosti (snímky obrazovky/gify vítány).
2. Sdělte nám, která budoucí vylepšení by měla největší dopad na váš pracovní postup.

Děkujeme, že nám pomáháte vytvářet lepší zážitek z recenze – čteme každý komentář!
R. M. R

[NiklasBr]

What use is there to merge statuses? Like, if I merge Blocked and Ready, do I get a Bready status?