GitHub code review shortcuts: the keys worth learning and where they stop helping

Most GitHub code review shortcuts go unused because nobody knows they exist. That is a real cost: reviewers spend their day in the Files changed tab reaching for the mouse to do things the keyboard already handles. Every shortcut in this piece is verified against GitHub’s keyboard shortcuts documentation; anything we could not verify there is left out. The second half is the honest part: where faster keys stop mattering because the surface itself is the bottleneck.

Press ? and read the map

The one shortcut that teaches the rest: typing ? on a GitHub page opens a cheat sheet of the shortcuts available on that page. The set is contextual, which is why most people never discover the review-specific keys; they only ever see the sheet on the dashboard, if at all. Open it once on the Files changed tab of a real PR and you will find the review keys documented below. Two site-wide keys worth binding into muscle memory while you are there: S or / focuses the search bar, and G then P jumps to the repository’s Pull requests tab.

Outside the diff, in regular code views, three more keys carry their weight. Pressing T activates the file finder so you can fuzzy-type a path, L jumps to a line number, and B opens the blame view, which is often the fastest way to answer the review question “why does this code exist at all” without leaving the browser. They are not review shortcuts strictly speaking, but a review that never needs surrounding context is rare, and these are how you get to that context quickly.

The GitHub code review shortcuts that earn their keep

On the Files changed tab, the documented set is small but load-bearing:

• T moves your cursor to the Filter changed files field. Type a path fragment, land on the file. This is the single highest-value key in a large diff.
• C opens the Commits dropdown to filter which commits are shown, which is how you scope the diff to one commit at a time instead of the whole branch.
• I shows or hides comments on diffs, useful when threads have buried the code they are arguing about.
• Click a line number, then Shift+Click another, to comment on a multi-line range instead of a single line.
• In a comment box, Cmd+G (Ctrl+G) inserts a suggestion block, and R quotes the text you have selected in your reply.

Batch the review, then submit once

The submit keys mirror GitHub’s two commenting modes: Cmd+Enter submits a standalone comment, while Cmd+Shift+Enter on the Files changed tab submits a review comment, the kind that stays pending until you finish the review. Pending-first is the right default. Your comments remain private and editable until you submit, so a misreading you catch on file nine can be fixed on file two before the author ever sees it, and the author receives one notification instead of eleven. None of this is about typing speed; it is about turnaround. Google’s engineering guidance treats review speed as a first-order health metric, and a reviewer who can enter, navigate, and batch a review without leaving the keyboard genuinely turns reviews around faster. Rounding out the set, the conversation page has its own documented keys: Q opens the reviewer request menu, A sets an assignee, and L applies a label, so even the triage work around a review can stay on the keyboard.

Where shortcuts hit the ceiling

Here is the honest limit. Shortcuts compress the mechanical part of review: getting to the diff, getting to the file, getting the comment in. They do nothing for the expensive part, which is building a model of the change. When a PR spans forty files, the web UI offers you the same flat, alphabetical file list no matter how fast you filter it. There is no way to read by architectural layer, no persistent sense of place across visits, and jump-to-definition simply does not exist in a diff view. We have made the long version of this argument before, and the practical comparison of reviewing locally versus in the browser covers what an IDE gives you that no shortcut can.

The right way to think about it

Learn the keys anyway. They are free, they compound over hundreds of reviews, and the cheat sheet takes two minutes to read. Just be clear about which problem they solve. If your reviews are slow because of clicking, shortcuts fix that this afternoon. If they are slow because the PRs are too large to hold in your head, the fix is structural: smaller units, commit-scoped reading, or a surface built for comprehension. Disclosure: that last category is why we build Pyor, which organizes the diff so the reading order makes sense rather than making you navigate an alphabetical list faster. Keys make a good surface quicker. They cannot make a flat one deep.