DEV Community: Pyor

What Is a Merge Queue and Why Do Teams Use One?

Othman Shareef — Tue, 20 Oct 2026 08:00:00 +0000

A merge queue is an automated system that merges pull requests one group at a time, testing each against the latest state of the target branch first, so changes that pass CI in isolation cannot break the branch when combined.

The short answer: What is a merge queue buying you? Certainty that green means green. Instead of trusting checks that ran against an old version of main, the queue builds the merge result that would actually land, runs CI on that, and only then merges. GitHub describes it as automating merges into a busy branch while ensuring the branch is never broken by incompatible changes.

What problem does a merge queue solve?

The stale-CI problem. Your pull request passed its checks, but it passed them against the main branch as it existed when CI last ran. By the time you press merge, five other pull requests have landed. Git may combine everything without a textual conflict and still produce a broken result: your change calls a function someone else just renamed, or relies on behavior another merge removed. Nothing in branch protection catches this, because each change was green on its own. The manual fix is updating your branch and re-running CI before merging, but on a busy repository that becomes a race: by the time your re-run finishes, main has moved again. Teams end up with developers babysitting the merge button, or with a main branch that breaks weekly for reasons no single PR caused.

What is a merge queue doing under the hood?

Instead of merging immediately, an approved and green pull request is added to a queue. From there, per the GitHub merge queue docs, the process looks like this:

The queue creates a temporary branch containing the speculative merge result: the latest target branch, plus the queued pull request, plus any pull requests ahead of it in line.
Required CI checks run against that merge group, not against the stale branch.
Pull requests merge in first-in-first-out order, each only after its group passes.
If a group fails, the failing pull request is removed from the queue and the speculative merges behind it are rebuilt without it.

Batching is the efficiency trick: by testing several queued pull requests together in one merge group, the queue validates many changes with one CI run and keeps throughput high even when each run takes twenty minutes. Batch size and merge method are configurable per repository, so teams can tune throughput against CI cost.

Who needs a merge queue?

The queue earns its complexity in proportion to merge traffic. Signals that you have crossed the line: developers regularly click update branch two or three times before a merge sticks, main breaks from combinations of individually green changes, or merge order has become something people coordinate in chat. High-traffic monorepos and teams practicing trunk-based development hit this earliest, since everyone is landing small changes into the same branch all day. If that is you, our deep dive on the GitHub merge queue covers setup, CI wiring, and the operational sharp edges.

What does a merge queue not do?

A queue automates the last step, not the judgment before it. It does not review code, and it does not loosen required reviews; a pull request still needs its approvals and passing checks just to enter. It also does not decide that a pull request is ready, which is auto-merge territory; the two compose nicely, with auto-merge queueing the PR the moment review completes. And it cannot save you from flaky tests: a queue amplifies test unreliability, because one flaky failure now ejects a pull request and re-runs everything behind it. Green must mean green for the queue to mean anything.

Frequently asked questions

Does a merge queue replace required reviews or CI?

No. It sits after them. A pull request still needs its approvals and passing checks to enter the queue; the queue then re-runs required checks on the speculative merge result. Think of it as a final gate that validates the combination, not the individual change.

What happens when a pull request fails in the merge queue?

It is removed from the queue rather than merged, and the queue rebuilds the speculative merges for the pull requests behind it without the failing change. The author fixes the problem and re-queues. Everything else keeps flowing, which is the point of the design.

Do small teams need a merge queue?

Usually not. The stale-CI problem grows with merge frequency. A team merging a few pull requests a day can just update branches before merging. Once merges start racing each other daily, or updating branches becomes a full-time chore, a queue starts paying for itself.

Graphite vs CodeRabbit for PR Reviews: An Honest Take

Othman Shareef — Mon, 19 Oct 2026 08:00:00 +0000

We sell neither Graphite nor CodeRabbit (we build Pyor, a review surface that sits next to both, so read this with that in mind). The two get compared as if they were the same kind of product, but Graphite is a pull request workflow and CodeRabbit is a review bot that joins the workflow you already have. We checked everything below against the vendors’ own pages and one open benchmark in October 2026, and where the sources disagree we say so.

The short answer: Graphite and CodeRabbit only overlap on one feature. CodeRabbit is a dedicated AI reviewer that comments on your PRs, on four git hosts, from $24 per developer a month. Graphite is a GitHub workflow platform (stacked PRs, a merge queue, an inbox) that also ships an AI reviewer, with unlimited AI reviews at $40 per user a month. On an open benchmark, CodeRabbit catches far more issues and Graphite stays quieter. Pick CodeRabbit if you want a bot, and Graphite if you want stacking.

What each one is for

Graphite is a pull request workflow platform for GitHub. Its core is stacked pull requests: a CLI and a VS Code extension that let you split a big change into a chain of small dependent PRs without the rebase bookkeeping. Around that sit a stack-aware merge queue, a PR inbox, Slack notifications, team insights, and an AI reviewer. Graphite’s homepage calls it “the AI code review platform”, but what your team adopts is the platform, and the reviewer comes with it.

CodeRabbit is a dedicated AI review agent. You install it, and it reviews every pull request with line comments, a summary, one-click fixes, and pre-merge checks. Per its docs it runs on GitHub, GitLab, Azure DevOps, and Bitbucket, in VS Code, Cursor, and Windsurf through an extension, and from a CLI before you commit. Your team branches and merges the same way it did before.

AI review quality on an open benchmark

Most “benchmarks” you will find for these two are run by a vendor, and the vendor tends to win. The one we trust most is Martian’s Code Review Bench, because its method and code are open source and Martian runs every tool itself rather than taking submitted results. It has two modes, and both include CodeRabbit and Graphite.

The offline benchmark uses 50 PRs from five open source projects (Sentry, Grafana, Cal.com, Discourse, and Keycloak) with human-verified “golden” comments, then has an LLM judge match each tool’s comments against them. In the snapshot dated September 8, 2026 (default judge and category profile), CodeRabbit scored 42.2% F1 with 59.5% recall and 32.6% precision. Graphite scored 14.1% F1: it made 12 correct comments and zero wrong ones, for 100% precision, but found only 7.6% of the known issues.

The live benchmark is the one we weigh more. It samples fresh merged PRs on GitHub where a bot commented, and counts a bot comment as useful when it matches a fix the developer made afterwards. Over December 25, 2025 to October 17, 2026, with the leaderboard’s filters cleared, CodeRabbit sat at 52.2% F1 (54.2% precision, 50.2% recall) across about 48,900 scored PRs. Graphite sat at 41.5% F1 (64.9% precision, 30.6% recall) across about 1,460. You only see Graphite once you clear the default volume filters, since it reviews far fewer public PRs than CodeRabbit does.

Both modes show the same trade. Graphite’s reviewer says little, and what it says is usually right. CodeRabbit says a lot more and catches a lot more, with more comments that go nowhere. Graphite’s own AI reviews page leans into that trade (it claims a negative comment rate under 5% in its own tests, without publishing the method). An older July 2025 test published by Greptile points the same way (CodeRabbit caught 44% of 50 planted bugs, Graphite 6%), but Greptile sells a competing reviewer and scored itself highest, so weigh it as a vendor claim.

Precision decides how much of your reviewers’ time the bot burns, and recall decides how much it saves them from missing. We cover why benchmarks disagree in how accurate AI code review really is. A two-week trial on your own PRs will tell you more than any of these numbers.

Pricing and free tiers in 2026

As of October 2026, Graphite’s pricing page lists annual prices only, and CodeRabbit’s lists annual prices with monthly prices in its FAQ.

	Graphite	CodeRabbit
Free	Hobby: personal repos only, limited AI reviews and chat	Free reviews on public repos; no free plan for private repos
Entry paid tier	Starter, $20/user/mo billed annually: org repos, AI reviews still limited	Essentials, $24/dev/mo annual or $30 monthly
Unlimited AI review	Team, $40/user/mo billed annually, which also adds the merge queue	No total cap; past an hourly per-developer allowance, $0.25 per reviewed file
Higher tiers	Enterprise, custom	Team $48 ($60 monthly), Advanced $72, Enterprise custom
Trial	30-day trial	14-day trial

For unmetered AI review on private org repos, Graphite starts at $40 a seat and CodeRabbit at $24. Graphite’s $40 also buys the merge queue and stacking workflow, so if you would not use those, you are paying for a platform to get a reviewer. Model CodeRabbit’s usage pricing before you commit: Essentials allows 5 reviews per developer an hour, and continued reviews bill per file, with an admin spending cap to stop surprises.

Workflow lock-in and who owns what

CodeRabbit is easy to leave. It is an app on your repos, so when you uninstall it, your PRs, branches, and merge process stay exactly as they were. You lose its configuration and the “learnings” it has collected from your team’s feedback. It also follows you across hosts, which matters if part of the org lives on GitLab or Bitbucket.

Graphite asks for more commitment, by design. The AI reviewer alone is not sticky: Graphite’s setup docs say it reviews all new PRs in the repositories you pick, with no stacking required. But $40 a seat is a lot to pay for the reviewer alone. You get your money’s worth when the team branches through the Graphite CLI and merges through its queue, and unwinding that means changing how everyone works. Its setup docs also only describe GitHub.

Graphite’s ownership has changed too. On December 19, 2025, Graphite signed a definitive agreement to join Cursor (the company is Anysphere). Both companies said Graphite would keep operating as an independent product, and Graphite’s post lists plans to combine its AI reviewer with Cursor’s Bugbot into one reviewer. Since then Graphite has shipped Cursor Cloud Agents inside Graphite (March 2026, for paid Cursor plans), and Cursor itself was acquired by SpaceX in August 2026. Graphite works the same today, but its reviewer may change shape, and its roadmap now follows Cursor’s.

If stacking is the draw, GitHub now ships native stacked pull requests in public preview, which we cover in GitHub stacked pull requests. Graphite is far more mature today, but it is no longer the only way to stack.

Who should pick which

Pick CodeRabbit if you want an AI first pass on every PR without changing your workflow, you are on more than one git host, or you want the reviewer that catches the most on the open benchmark and can live with more comments to triage.
Pick Graphite if your team will actually adopt stacked PRs and a merge queue. Stacking gets you smaller PRs, and the reviewer rides along as a quiet extra that rarely wastes your time.
Use both if you want Graphite’s stacking and CodeRabbit’s catch rate. Turn Graphite’s reviewer off on those repos, or you will read two bots on every PR.

If you are looking for a Graphite competitor because you only ever used the reviewer, you have the clearest case for switching: a dedicated bot does that job for less. Our Graphite alternatives and CodeRabbit alternatives posts map the rest of the field.

When neither is the bottleneck

On a lot of teams (ours included), the slow part of review is a human reading a big diff. The bottleneck shifted from producing code to reviewing it. A bot adds comments to read and stacking changes how PRs are cut, but if your PRs are a 20K-line migration that cannot be stacked, or agent-written changes that land faster than anyone reads them, a reviewer bot hands you one more layer of text, and you still have to read the code anyways.

That is the problem we built Pyor for (yes, this is the plug, kept short). Pyor is a review surface for GitHub PRs, on the web and as a desktop app for macOS, Windows, and Linux. It is not an AI reviewer, and its AI posts no comments: it groups and labels the diff and drops short hints so you read the code that matters first and skim the noise. It adds PRs to GitHub’s merge queue rather than running its own, and while it does not create stacks, it surfaces GitHub native stacks while you review. Pyor is free for individuals and $7.99 per seat a month for orgs, and it works next to either tool here. The feature-by-feature versions are in Pyor vs Graphite and Pyor vs CodeRabbit.

Frequently asked questions

Is Graphite or CodeRabbit better for AI code review?

If the AI reviewer is all you want, CodeRabbit. On Martian’s open Code Review Bench it catches far more of the issues developers actually fix, while Graphite’s reviewer is quieter and more precise but misses most of them. What you pay Graphite for is stacked pull requests and a merge queue, and the reviewer comes with them.

Is CodeRabbit a Graphite competitor?

Only on the AI review part. CodeRabbit is a dedicated review bot that plugs into GitHub, GitLab, Azure DevOps, or Bitbucket. Graphite is a workflow platform for GitHub built around stacked pull requests, a merge queue, and an inbox, with an AI reviewer as one feature.

Can you use Graphite and CodeRabbit together?

Yes. Graphite’s AI reviews are switched on per repository or per organization, and CodeRabbit installs as its own app, so a team can stack and merge with Graphite and let CodeRabbit post the review comments. You pay for both, and you read both if both are on.

Who owns Graphite now?

Graphite signed a definitive agreement in December 2025 to be acquired by Cursor (the company is Anysphere), and both said Graphite would keep running as an independent product. Cursor itself was acquired by SpaceX in August 2026. Graphite is still sold and priced on its own.

Interdiff Meaning: What an Interdiff Is in Code Review

Othman Shareef — Sun, 18 Oct 2026 08:00:00 +0000

An interdiff is the diff between two versions of the same change. Instead of re-reading a whole pull request after an update, you read only what the author changed between revision one and revision two.

The short answer: The interdiff meaning is easiest to see as a diff of diffs: version one of a patch said how the code should change, version two says it differently, and the interdiff shows exactly where the two disagree. It answers the only question a returning reviewer has: what is different since I last looked?

Why does re-review need an interdiff?

First review is well supported everywhere: you get a diff against the base branch and you read it. The second review is where tooling has historically gone quiet. The author pushed fixes, maybe rebased, maybe reworked a section you never commented on, and the platform shows you either the same full diff again or a per-commit view polluted by rebase noise. So reviewers face a bad menu: re-read everything (nobody does), read nothing and approve (everybody eventually does), or reconstruct the delta by hand. An interdiff replaces that menu with the right default: show me revision two minus revision one. We walk through the workflow consequences in our piece on re-reviewing pull requests with interdiffs; this article is just the definition underneath it. The cost of getting this wrong is quiet: the revision that introduces a bug is precisely the one nobody re-read, because it arrived after the hard first pass was already done. Reviewers approve version one carefully and version four on trust, and the delta between those two readings is where regressions live.

Interdiff meaning in git: the range-diff command

Git ships the idea natively as git range-diff, which compares two commit ranges, typically two versions of the same branch, and shows which commits correspond, which were added or dropped, and how each corresponding commit changed. After a force-push you can run something like git range-diff main old-tip new-tip and read precisely what the rework did, rebase and all. The name interdiff itself is older: a standalone utility of that name compared two patch files back when changes traveled as emailed patches, and kernel reviewers still routinely ask contributors to post a range-diff alongside v2 of a patch series.

Where do patchsets come from? The Gerrit heritage

Gerrit, the review system built around the Android project, made revisions first-class: every push to a change under review becomes a numbered patchset, and the UI lets a reviewer diff any patchset against any other. Comment positions carry across revisions, so a thread you opened on patchset 2 is still anchored correctly when you are comparing patchset 2 to patchset 5. That lineage is why review veterans talk about patchsets and interdiffs in the same breath: Gerrit demonstrated that re-review is a solved problem when versions of a change are modeled explicitly rather than as an afterthought.

What GitHub gives you, and where it falls short

GitHub approximates the interdiff. It can show changes since your last review, and viewed-file checkmarks reset when a file changes, which together cover the easy case: new commits appended to the same history. The approximation degrades exactly where you need it most. A rebase or force-push rewrites the commits the comparison was anchored to, comments go outdated, and the since-review view can fall back to showing you everything again. There is no patchset picker, no durable revision history to diff against. Until the platform models revisions properly, reviewers cover the gap with git range-diff locally or with review tools built around the returning reviewer (disclosure: our own Pyor is one attempt at that). However you get one, the test of a review tool is the second look, not the first.

A commit rail as the revision picker: select a commit and the diff re-scopes to that span.

Frequently asked questions

What is the difference between an interdiff and git range-diff?

An interdiff is the concept: the difference between two versions of a change. git range-diff is the built-in git command that produces one, comparing two commit ranges and showing how each commit changed between them. Older tooling also had a literal interdiff utility for comparing patch files.

Does GitHub show an interdiff?

Approximately. GitHub can show changes since your last review, and its viewed-files checkmarks reset when a file changes. But a force-push rewrites history and can break that view, and there is no first-class revision picker like Gerrit patchsets, so the approximation fails exactly when rebases happen.

Why not just re-read the whole pull request?

Because full re-reads do not scale and reviewers do not actually do them. Faced with a 40-file PR updated for the third time, most reviewers skim and approve. An interdiff shrinks the third look to the handful of lines that changed, which keeps re-review honest.

What Are Stacked Pull Requests?

Othman Shareef — Fri, 16 Oct 2026 08:00:00 +0000

Stacked pull requests are a chain of dependent PRs where each one builds on the branch of the previous. A large change is split into small steps, reviewed independently, and merged from the bottom of the stack up.

The short answer: What are stacked pull requests solving? The conflict between how developers work and how reviewers read. Big features are built in sequence, but nobody reviews a 2,000-line diff well. A stack keeps the author moving on step three while steps one and two are under review, and every reviewer only ever sees a small, coherent piece.

How do stacked pull requests work?

Instead of one feature branch targeting main, you cut a chain: branch A off main, branch B off A, branch C off B. Each branch becomes a pull request whose base is the branch below it, so every diff shows only that step. Say you are adding an export feature: PR one adds the data model, PR two the API endpoint on top of it, PR three the UI on top of that. Review and merge run bottom up. PR one merges into main first; PR two is then retargeted onto main and merged; PR three follows. When a lower PR changes in response to review, the branches above it are rebased so the stack stays consistent. That rebase cascade is the tax the whole workflow lives with, and we will come back to it.

What are stacked pull requests for?

Small diffs get better reviews; that is one of the most consistent findings in review practice, and it is the core argument in our guide to how big a pull request should be. The problem is that real features are often irreducibly large. Without a stack, the author faces a bad choice: ship one huge PR that gets skimmed, or sit blocked waiting for each small PR to merge before starting the next. Stacking removes the wait. The author keeps building on their own unmerged work while review proceeds underneath, and each reviewer gets a diff sized for actual reading. It is the same instinct behind atomic commits, promoted from commit granularity to PR granularity.

What tools support stacking?

GitHub has begun building stacks in natively: as InfoWorld reported, GitHub added stacked pull requests specifically to speed up review of complex changes. Since 30 July 2026 it has been in public preview for every repository, no waitlist, though still labelled subject to change; we track the details in our deeper look at GitHub stacked pull requests. In the meantime the workflow is well served by third-party tools (Graphite is the best known) that automate the branch bookkeeping: creating the chain, restacking after changes, and retargeting PRs as lower ones merge. And plain GitHub works too, manually, for shallow stacks. The broader tool landscape is covered in our roundup of GitHub PR review alternatives.

What do stacks cost?

The honest ledger has three entries. First, rebase overhead: every change to a lower PR ripples upward, and without tooling you pay that in manual rebases and force-pushes. Second, review coordination: reviewers of PR three are looking at code built on unreviewed foundations, and feedback on PR one can invalidate work above it. Third, platform friction: force-pushing rebased branches can confuse review state, resetting what reviewers had already read. None of this is disqualifying, but it means stacks are a deliberate practice, not a free upgrade. Use them when the work is genuinely large and sequential, keep each layer independently understandable, and let the bottom of the stack merge fast. A stack whose base PR sits unreviewed for a week is just a big PR with extra steps.

Frequently asked questions

Can you create stacked pull requests on GitHub without extra tools?

Yes. Open each branch against the one below it instead of against main, then merge from the bottom and retarget as you go. It works, but keeping the stack rebased by hand gets tedious past two or three PRs, which is why dedicated stacking tools exist.

How is a stacked pull request different from a normal branch with many commits?

A multi-commit branch still lands as one pull request with one review and one merge. A stack splits the same work into separate PRs, each with its own reviewer, discussion, CI run, and merge, so review happens in small units while the work stays connected.

When are stacked pull requests not worth it?

When the change is already small, or when the pieces are truly independent and could just be separate unrelated PRs. Stacks pay off when work is large and sequential. If your team rarely reviews within a day, the coordination cost of a stack can exceed its benefit.

Nit Code Review Meaning: What a Nit Comment Is

Othman Shareef — Wed, 14 Oct 2026 08:00:00 +0000

In code review, a nit is a minor, non-blocking comment: a small point about style, naming, or polish that the reviewer wants to mention but does not consider a reason to hold up approval. The word is short for nitpick.

The short answer: The nit code review meaning, compressed: prefixing a comment with nit: tells the author this is worth a glance, not a fight. It keeps small feedback flowing without turning every review into a negotiation, and it only works if both sides honor the label: reviewers keep nits genuinely optional, authors read them anyway.

Nit code review meaning: what does the prefix signal?

A review comment carries two messages: the observation itself, and how much the reviewer cares. The nit: prefix makes the second part explicit. It says: I noticed this, I would do it differently, and I am approving either way. That framing is the whole value. Without it, the author has to guess whether a comment about a variable name is a passing thought or a condition for approval, and guessing wrong in either direction wastes a round trip. The Conventional Comments spec generalizes this idea into a full vocabulary: labels like suggestion, question, issue, and nitpick, plus decorations like (non-blocking) that make severity unambiguous. You do not need the whole system to benefit; even adopting nit: alone removes a surprising amount of friction.

Nit etiquette for reviewers

A nit is a courtesy, and it stays one only under a few rules:

Mean the label. If you would withhold approval over it, it is not a nit. Do not write nit: and then argue three replies deep.
Say the fix, not just the flaw. A nit that names the preferred spelling costs the author seconds; a vague one costs a guess. Our guide to review comments that land applies doubly to small ones.
Ration them. Ten nits on a solid change read as hostility, however polite each one is. We covered the failure mode at length in our piece on code review nitpicks.
Automate the recurring ones. A nit you have typed three times is a linter rule waiting to be written. Machines nitpick for free and nobody resents them.

Nit etiquette for authors

Non-blocking does not mean ignorable. The gracious move is to fix cheap nits in the next push, reply briefly to the ones you are declining, and resolve the threads either way so the reviewer is not left wondering. Silently skipping every nit trains reviewers to escalate small feedback into blocking feedback, which makes reviews slower for everyone. Treat nits as free polish from someone who read your code closely, because that is what they are.

There is a mechanical courtesy here too: on GitHub, who resolves the thread matters. For a nit you fixed, resolving it yourself with a quick done is fine. For one you are declining, leave the thread open long enough for the reviewer to see your reasoning before it disappears. We cover the finer points in our guide to resolve conversation etiquette, but the principle is short: a nit deserves an acknowledgment, not a burial.

When is a nit not a nit?

The label gets misused in both directions. Reviewers sometimes soften real problems with it: a swallowed exception or an off-by-one is not a nit, and prefixing it as one buries a defect under politeness. The reverse misuse is the blocking nit, where a style preference arrives labeled as small but is defended like a design principle. A quick test for both: would this comment survive being ignored? If ignoring it risks a bug, drop the prefix and say so plainly. If ignoring it costs nothing but your aesthetic satisfaction, keep the prefix and let it go. The nit convention works precisely because the label is honest; spend it carelessly and your reviews lose their signal.

Frequently asked questions

Do I have to fix nit comments before merging?

Usually no. A nit is non-blocking by definition, so the author can fix it, defer it, or decline it with a short reply. Teams differ on convention, though: some expect nits to be addressed in the same pull request, so check what your reviewers actually expect.

Where does the term nit come from?

It is short for nitpick, picking small insects from hair, which became slang for fussing over trivial details. Code review adopted the abbreviation as a comment prefix so reviewers could flag minor polish issues while making clear the feedback is small and not a blocker.

How many nits are too many?

When nits outnumber substantive comments, the review starts to read as criticism of the author rather than the code, and the important feedback drowns. A common ceiling is a handful per review; past that, ask whether a linter or formatter should be enforcing the pattern instead.

What Does LGTM Mean in Code Review?

Othman Shareef — Mon, 12 Oct 2026 08:00:00 +0000

LGTM means looks good to me. In code review it is shorthand for approval: the reviewer has read the change, found nothing blocking, and is happy for it to merge.

The short answer: So what does LGTM mean when you actually type it? It is a claim, not a pleasantry: I read this change carefully enough to vouch for it. On a two-line fix that claim is cheap to make honestly. On a forty-file change it is either the product of real work or it is rubber-stamping wearing a friendly acronym.

Where does LGTM come from?

The acronym predates modern tooling; it grew up on open source mailing lists and early review threads as a compact way to say the patch passes. What made it a term of art is that big engineering cultures formalized it. At Google, the internal review tool Critique makes LGTM a literal, named approval state that reviewers grant, as described in Modern Code Review: A Case Study at Google. From there the word leaked into the general vocabulary: GitHub reviewers write it in approval comments, bots print it, and stickers exist. The mechanics differ by platform, but the meaning has stayed stable for decades: a named human is signing off.

What does LGTM mean in practice?

An approval asserts more than most people think. When you approve, you are telling your team three things: the change does what its description claims, you looked hard enough to catch the problems you are qualified to catch, and you are comfortable with this code running in production with your name in the review log. That is why the flip side matters too: knowing when to request changes instead is what keeps the approval meaningful. A reviewer who never blocks anything is not agreeable; they are absent. LGTM only carries information if it was possible for you to say something else.

When is a bare LGTM fine, and when is it rubber-stamping?

A bare LGTM is perfectly good feedback when the change is small, the behavior is easy to verify, and the author is trusted on this part of the codebase. A dependency bump with green CI, a typo fix, a config value change you double-checked: adding paragraphs of commentary there is ceremony for its own sake. The trouble starts when LGTM becomes the default response to everything, including changes nobody could have read in the time between request and approval. We wrote a whole piece on LGTM culture and code review theater: the short version is that the acronym is not the problem, the missing reading is. A useful self-test: if you cannot name one specific thing you checked, you did not review it, you witnessed it.

Related shorthand: PTAL, nit, WIP

LGTM lives in a small family of review abbreviations worth knowing:

PTAL : please take a look. A request for review, or for re-review after fixes have been pushed.
nit : short for nitpick. Prefixes a minor, non-blocking comment; we cover the etiquette in our piece on review nitpicks.
WIP : work in progress. Marks a pull request that is not ready for formal review; on GitHub this is now usually a draft PR instead.
ACK / NACK : acknowledge or reject, an older sibling of LGTM from mailing list review culture.

All of this shorthand exists to keep review fast without making it empty. LGTM is the smallest possible review comment, and that is exactly why it deserves the discipline: it should compress a real judgment, not replace one. If your team wants the compression without the emptiness, make the convention explicit: a bare LGTM is reserved for trivial changes, everything else gets one line about what was checked, and an LGTM you feel pressured into giving is really a signal to slow down. Shorthand works best when everyone knows exactly how much weight it carries.

Frequently asked questions

Is LGTM the same as approving a pull request?

Not automatically. LGTM is just text; on GitHub, approval is a formal review state that satisfies branch protection rules. Many reviewers write LGTM in the comment of an approving review, so in practice the two travel together, but only the Approve action unblocks the merge.

What does PTAL mean?

PTAL stands for please take a look. Authors use it to ask a reviewer to look at a change, or to look again after they have pushed fixes. It is the request side of the exchange that LGTM closes: PTAL asks for review, LGTM signals the reviewer is satisfied.

Is it rude to reply with just LGTM?

Not rude, but it can be low-signal. On a small, easily verified change, a bare LGTM is fine. On anything substantial, one sentence about what you checked makes the approval mean something and tells the author which parts were actually read rather than skimmed.

What Is a Pull Request Review? A Plain Definition

Othman Shareef — Sat, 10 Oct 2026 08:00:00 +0000

A pull request review is a structured check of proposed code changes before they merge. A teammate reads the diff, leaves comments, and either approves the change or requests changes, so problems are caught while they are still cheap to fix.

The short answer: What is a pull request review, in one breath? It is the checkpoint between written code and shipped code: a second person confirms the change does what it claims, fits the codebase, and will not surprise whoever maintains it next. The approval is an assertion, not a formality.

How does a pull request review work on GitHub?

The author opens a pull request, a proposal to merge one branch into another, and requests reviewers, either by hand or automatically through code owner rules. The reviewer opens the Files changed tab, reads the diff, and attaches comments to specific lines. Comments can carry questions, requested fixes, or concrete suggestions the author can apply with one click. When the reviewer is done reading, they submit the review with one of three verdicts:

Comment : feedback without a judgment, useful when you have notes but no authority or no strong opinion on merging.
Approve : the change is good to merge as far as this reviewer is concerned.
Request changes : the change should not merge until specific problems are addressed.

The author replies, pushes fixes, and asks for another look; each comment becomes a thread that gets resolved as the discussion settles. Branch protection rules can make all of this binding by requiring one or more approvals before the merge button works, which turns review from a courtesy into a gate.

What is a pull request review actually for?

Ask most developers and they will say finding bugs. That is part of it, but the research says it is not the biggest part. A well-known Microsoft study of code review in practice, Expectations, Outcomes, and Challenges of Modern Code Review, found that while defect finding is the top stated motivation, the actual outcomes lean toward code improvement, alternative solutions, and knowledge transfer. Review is how a team keeps a shared mental model of its own codebase: the reviewer learns what changed, the author learns what the team expects, and the code ends up readable by more than one person. We have written before about what reviews actually catch, and the honest answer is: fewer bugs than you hope, more understanding than you expect. Both are worth paying for.

What does a good pull request review look like?

A good review starts before the line-by-line reading: understand what the change is supposed to do, then check whether it does that, then look at how. Concretely, strong reviewers tend to do a few consistent things:

Read the description and linked issue first, so the diff has context.
Start with the riskiest files, not the first ones alphabetically.
Comment with reasons, not just verdicts, and separate blocking from optional.
Approve explicitly when satisfied instead of going silent.

If you want the full checklist treatment, we keep a practical code review checklist that covers correctness, tests, security, and readability in order. And when the diff is overwhelming, the problem is usually the pull request, not you; there are concrete tactics for reviewing large pull requests without skimming.

Where do pull request reviews go wrong?

Two failure modes cover most of it. The first is the rubber stamp: an approval given without real reading, which keeps the ritual while deleting the value. The second is the bottleneck: reviews that sit for days, punishing exactly the authors who split their work into small, reviewable pieces. Both have the same root cause, review treated as interruption rather than as first-class engineering work. Teams that treat it as the latter, with time carved out and expectations set, get the defect prevention and the shared understanding. Teams that do not get theater. The definition is simple; the discipline is the hard part.

Frequently asked questions

What is the difference between a code review and a pull request review?

Code review is the general practice of having another person examine code changes. A pull request review is the specific form most teams use today: the review happens on a pull request, inside a platform like GitHub, with comments anchored to the diff and an explicit approve or request changes verdict.

Who can review a pull request?

Anyone with read access to the repository can comment on a pull request. Approving or requesting changes usually requires write access, and branch protection rules can require approval from specific people, such as code owners, before the change is allowed to merge.

How long should a pull request review take?

Minutes to a few hours of focused reading for a well-sized change; the elapsed time matters more. Many teams target a first response within one business day, because waiting reviews block the author. If a review takes days of reading, the pull request itself is probably too large.

GitHub Auto Merge: Good Uses and the Stale Approval Trap

Othman Shareef — Thu, 08 Oct 2026 08:00:00 +0000

GitHub auto merge is one of those features that is either a pure quality-of-life win or a quiet hole in your review process, depending entirely on settings most teams have never audited. The behavior itself is simple and documented in GitHub’s auto-merge docs: enable it on a PR, and the PR merges itself the moment all requirements are met. The interesting questions are when that is a good idea, and what “requirements are met” can silently fail to mean.

The short answer: Auto-merge is excellent for exactly one situation: the human review is done and only machinery remains. Approved and waiting on CI, or a dependency bump you have actually read. The trap is stale approvals: if branch protection does not dismiss approvals when new commits are pushed, auto-merge will happily merge code added after the reviewer looked. Audit that setting before you trust the feature with anything.

How GitHub auto merge actually works

The verified mechanics: auto-merge must be allowed at the repository level, and then people with write permissions can enable it on individual pull requests. Per the docs, the option is relevant for PRs that cannot merge yet because requirements are unmet, and once enabled “the pull request will merge automatically when all required reviews are met and all required status checks have passed.” You choose the merge method and can set the commit message when enabling. One safety behavior worth knowing: if someone without write permissions pushes new changes to the head branch, or switches the base branch, auto-merge is disabled automatically, so a drive-by commit from an outside contributor cannot ride an armed auto-merge into your default branch. Note the asymmetry, because it matters later: pushes from people with write access do not disarm it.

The good uses

The canonical case is approved-pending-CI. Review is finished, the reviewer signed off, and the only thing between the branch and main is a forty-minute pipeline. Without auto-merge, someone has to remember to come back, which in practice means the PR merges hours later or the next morning, and every hour it sits is another chance for a conflict to appear. Enabling auto-merge at approval time converts “merged whenever someone remembers” into “merged on green.” The second good case is routine dependency updates, with a hard caveat: after a real review. A Renovate bump whose changelog and diff you have actually examined is a fine thing to auto-merge behind CI. Auto-merging dependency PRs you never opened is a different practice, and it is not review. The tell is simple: if you could not say what changed in the dependency, the merge was unattended, whoever technically clicked approve.

The trap: stale approvals plus new commits

Here is the failure sequence, and every step is individually reasonable. A reviewer approves. The author enables auto-merge. CI fails on a flake or a lint error, so the author pushes another commit, or force-pushes a rebase with a quick fix folded in. The author has write access, so auto-merge stays armed. And if your branch protection does not dismiss stale approvals when new commits are pushed, the original approval still counts. The instant checks go green, the PR merges, including commits no reviewer ever saw. Nothing malicious happened; the process just never asked anyone to look again. Whether it can happen to you is one checkbox: the dismiss-stale-approvals setting in your required-review rules, which we cover in branch protection and required reviews. If auto-merge is enabled anywhere, that setting stops being optional hygiene and becomes the thing standing between “approved code merges” and “approved-ish code merges.”

Auto-merge reviews nothing

A subtler cost shows up in culture. Once merging is automatic, approval becomes the last human act in the pipeline, and anything that erodes approval quality now flows straight to main with no further pause for doubt. Auto-merge fires on requirements-satisfied; it cannot distinguish a careful approval from a reflexive LGTM. Teams sometimes experience this as “auto-merge lowered our quality,” but the feature only removed the slack that was hiding rubber stamps. If merges feel scarier when automated, the review step was weaker than assumed, and that diagnosis is worth its own conversation. The same logic cuts the other way, constructively: a team whose approvals are consistently trustworthy loses nothing to auto-merge and gains hours of unblocked time per week. The feature is a mirror, not a gate. It shows you what your approvals were already worth.

The checklist before you trust it

Dismiss stale approvals is on for protected branches, or you have a conscious, written reason it is not.
Required checks actually cover the risk. Auto-merge waits only on checks you marked required; an optional-but-important suite will not hold the merge.
Approvals mean review happened. Automation amplifies whatever your approval habit is, stamp or scrutiny.
High-throughput repos consider a merge queue on top, which serializes landings; we cover it in our merge queue explainer.

Pass that audit and auto-merge is what it should be: the removal of a pointless wait, after the reviewing is truly done. Fail it, and the feature will do exactly what you configured, which is not the same as what you intended.

Frequently asked questions

How does auto-merge work on a GitHub pull request?

Someone with write permission enables auto-merge on an individual PR, after the feature is turned on at the repository level. The PR then merges automatically once all required reviews are met and all required status checks have passed. You pick the merge method up front, and GitHub disables auto-merge if someone without write access pushes to the branch or the base branch changes.

Is it safe to enable auto-merge before CI finishes?

That is its best use, with one condition: the human review must already be genuinely complete. If the code is approved and only checks remain, auto-merge just removes the ritual of returning to click a button. The risk appears when new commits can land after approval; unless branch protection dismisses stale approvals, those commits can merge unreviewed.

Does auto-merge skip code review?

No. Auto-merge respects your branch protection rules, so required reviews still gate the merge. But it also cannot add scrutiny: it fires the moment requirements read as satisfied, whether the approval was thoughtful or a rubber stamp, fresh or stale. Auto-merge automates the clicking, and it inherits exactly the review rigor your settings and culture enforce.

GitHub Resolve Conversation: Who Should Close the Thread

Othman Shareef — Tue, 06 Oct 2026 08:00:00 +0000

Every team that reviews code on GitHub eventually has the argument, usually in a PR thread that was already tense. Someone hits the GitHub resolve conversation button on a comment they did not write, and the person who wrote it notices. Was the concern addressed, or dismissed? GitHub is no help here: the button collapses the thread and marks it resolved, and the platform is agnostic about who clicks it. The etiquette is entirely a team norm, which means most teams have three conflicting norms and no document.

The short answer: The defensible default: the author replies to the comment and pushes the fix, and the commenter resolves the thread. Whoever raised the concern is the only person who can confirm it was actually met, so resolution should be their acknowledgment, not the author’s self-grade. The exception is feedback the reviewer pre-labeled as optional: take-it-or-leave-it nits are the author’s call, and the author may resolve them directly.

The GitHub resolve conversation norm nobody writes down

There are two coherent positions. Author-resolves says the author is the janitor of their own PR: they act on feedback, they tidy the threads, and a wall of resolved conversations signals a change that is ready. Commenter-resolves says a thread is a question addressed to its author, and only the person who asked can say the answer satisfied them. Both work when everyone shares the assumption. What breaks teams is the mixture: an author who thinks resolving is bookkeeping meets a reviewer who thinks it is an answer to their question being closed unread. The classic Microsoft research on modern code review found that review is as much a communication channel as a defect filter, and the resolve button is part of that channel; clicking it transmits something whether you intend to or not.

What the ambiguity actually costs

The cost lands at re-review time. A reviewer coming back after the author pushes fixes faces a stack of threads in mixed states: some resolved by the author, some open but answered, some open and forgotten. Which ones still need their attention? If resolved might mean “fixed and verified” or might mean “the author decided it was fine,” the reviewer has to reopen and reread everything to be safe, which is precisely the wasted pass we describe in re-reviewing pull requests. Unresolved-thread limbo has a second failure mode: PRs that merge with open threads nobody can later interpret. Six months on, an open thread that says “this will break under concurrent writes” with no reply is either a landmine or noise, and nobody can tell which. The archaeology cost is real: someone eventually spends an afternoon reconstructing whether a warning was heeded, and the thread state could have answered in one glance.

A defensible default

The protocol that keeps the signal clean:

The author replies to every thread , even trivially: “fixed in the next push,” “disagree, here is why,” or “good catch, done.” A push with no reply forces the reviewer to diff-hunt for whether their comment was acted on.
The author pushes the fix and references it in the reply when the fix is not obvious.
The commenter resolves. They raised the concern; their click is the confirmation it was met. Resolution becomes a tiny handshake instead of a unilateral declaration, and the resolved state acquires a precise meaning: the person who asked is satisfied. That precision is the entire point of having a norm.
Stale threads default to a ping, not a resolve. If the commenter goes silent for days, the author asks once, then resolves with a note. Silence should not block merges forever, but the note preserves the record.

The exceptions that prove the rule

Commenter-resolves is the default, not a ritual. Feedback the reviewer explicitly marked as optional, the Conventional Comments style of nit: or suggestion (non-blocking):, transfers the decision to the author, and with it the resolve. Making the author round-trip every take-it-or-leave-it comment back to the reviewer is ceremony with no information content, and it is how teams learn to hate the protocol. The prerequisite is honest labeling: reviewers have to actually mark their nits as nits, a discipline we cover in our piece on nitpicks. The other sane exception is threads the commenter is no longer around to resolve; departed colleagues should not hold locks on your merge button.

Write the norm down

Whatever you choose, choose it in a document instead of in each PR separately. Two sentences in the contributing guide end the argument permanently: who resolves, and what the exception for pre-labeled nits is. New hires absorb it in their first PR instead of guessing, and nobody has to litigate intent inside a thread that is already about something else. This is the general lesson of healthy review culture: friction comes less from strictness than from unstated rules enforced inconsistently. A team that resolves threads predictably gets a concrete payoff, because thread state becomes trustworthy. Resolved means confirmed, open means pending, and a re-reviewer can navigate by that state instead of rereading the whole conversation. It is a one-line policy that buys back real review time every single week.

Frequently asked questions

Who should resolve a conversation on a GitHub pull request?

GitHub does not enforce an answer, so it is a team norm. The default we recommend: the author replies and pushes the fix, and the person who raised the comment resolves the thread, because they are the one who can confirm the concern was actually addressed. The clean exception is comments the reviewer explicitly labeled as optional nits, which the author may resolve directly.

Is it rude to resolve someone else’s review comment?

Rude is the wrong frame; the issue is information. When an author resolves a reviewer’s thread, they are declaring the concern handled on the reviewer’s behalf, and the reviewer may never see the reply because collapsed threads are easy to skip. On teams without an explicit norm it often reads as dismissive even when the fix is genuinely correct.

What happens when review threads are left unresolved?

The PR accumulates ambiguity. A reviewer returning for a second pass cannot tell which threads represent accepted fixes, open disagreements, or things the author simply missed, so they either reread everything or approve with doubts. Unresolved threads are exactly the kind of state that makes re-review expensive, which is a cost teams routinely underprice.

GitHub Mark File as Viewed: Keep Your Place in Big PRs

Othman Shareef — Sun, 04 Oct 2026 08:00:00 +0000

Buried in the corner of every file header on the Files changed tab is the most underrated control in GitHub’s review UI. The GitHub mark file as viewed checkbox does one small thing: it remembers which files you have already read. In a five-file PR that is pointless. In a fifty-file PR it is the difference between a systematic pass and rereading the same test fixture four times. This piece covers the verified behavior, the workflow that gets the most from it, and the gaps that eventually send you looking for more.

The short answer: Mark a file as viewed and GitHub collapses it and advances a progress bar in the PR header; if the file changes later, it is automatically unmarked. That makes viewed state a reliable place-keeper within a review session on a large PR. Its limits are just as real: no folder-level marking, progress evaporates when the author force-pushes broadly, and the state records nothing about what you concluded, only that you looked.

What the GitHub mark file as viewed checkbox does

The behavior, verified against GitHub’s docs on reviewing proposed changes: after you finish reviewing a file, you can mark it as viewed and the file collapses. The progress bar in the pull request header shows how many files you have viewed. And the detail that makes the feature trustworthy: “If the file changes after you view the file, it will be unmarked as viewed.” That last rule matters. A place-keeper that lied about staleness would be worse than none, because you would skip files that changed under you. GitHub chose correctness over comfort here, and it is the right call.

Why place-keeping matters in large PRs

Reviewing a large diff is fundamentally a working-memory problem: you are building a mental model faster than the file list can erode it. Every time you lose your place, you pay a re-orientation tax, scrolling to figure out what you have covered. PRs are hard to review in large part because the diff view gives you no narrative structure, and on a big change the viewed checkbox is the one piece of state that survives a coffee break. Used with discipline, it turns an amorphous wall of files into a shrinking queue, which is also the core move in our guide to reviewing large pull requests: make progress visible, or fatigue will make the decisions for you. There is a secondary benefit that goes underappreciated: the progress bar is a cheap honesty check. If you approved a forty-file PR and the bar says nine files viewed, you know exactly what kind of review that was, and so do you the next time you are tempted to repeat it.

Pair it with the file filter

Viewed state gets sharper when combined with the file filter dropdown, documented in filtering files in a pull request. You can filter the diff by file extension, by lack of an extension, by code ownership, or by dotfiles, and you can temporarily hide deleted files or files you have already viewed. The combination is the workflow: filter to one slice of the change, read it, mark as you go, hide viewed files, and watch the remaining set shrink to zero. On a mixed PR, filtering to .sql first, then source, then tests imposes at least a crude reading order on a list that is otherwise alphabetical. The file tree helps here too, with one documented quirk: it does not display if your screen is too narrow or if the PR contains only a single file, so on a laptop with a split screen you may be navigating by filter alone.

The gaps

No folder-level marking. Two hundred files of generated code under one directory means two hundred clicks. Filters can hide slices, but nothing marks a subtree as dealt with.
Resets are all or nothing per file. The auto-unmark is correct, but a rebase that touches every file wipes your progress wholesale, and nothing tells you what changed inside each unmarked file. That pain is the subject of our piece on re-reviewing with interdiffs: what you want after a push is the delta since your last read, not a fresh start.
No memory of conclusions. Viewed records that you looked, not what you thought. Come back Monday and the checkbox cannot tell you which files worried you.

A workflow that gets the most out of it

Within GitHub, the discipline that works: first sweep the trivial tail (lockfiles, snapshots, generated output) and mark it viewed immediately, so the progress bar reflects real work. Then filter by slice, read in dependency order as best you can, and leave unviewed anything you intend to revisit, treating the unviewed set as your literal queue. Comment as you read so conclusions live somewhere. Disclosure: the ceiling you eventually hit here, wanting reading order, grouping, and place-keeping that survives a force-push, is what we built Pyor for; it organizes the diff and scopes it per commit so your place is structural, not a row of checkboxes. But even with no new tools, viewed state used deliberately beats the default of scrolling and hoping.

Folder-level viewed: two snapshot folders marked viewed in two clicks, and the counter moves to 14 of 18 without touching a single file.

Frequently asked questions

What happens when you mark a file as viewed on GitHub?

The file collapses in the Files changed tab, and the progress bar in the pull request header updates to show how many files you have viewed. The state is yours alone; it does not signal approval to anyone else. If the file changes after you view it, GitHub automatically unmarks it as viewed so you know to look again.

Does viewed state persist if the author pushes new commits?

Partially. Files untouched by the new commits stay marked, but any file that changed is unmarked automatically, per the GitHub docs. That reset is the honest behavior, since your earlier read no longer covers the new content, but it also means a rebase or wide-reaching push can wipe most of your progress in one stroke.

Can you mark a whole folder as viewed?

No. Viewed state is strictly per file; there is no folder-level checkbox in the Files changed tab. The closest workaround is the file filter dropdown, which can temporarily hide files you have already viewed, or filter by extension, code ownership, or dotfiles to shrink the visible set while you work through a directory.

GitHub Review Requested Filter: Build a Real Review Inbox

Othman Shareef — Fri, 02 Oct 2026 08:00:00 +0000

The GitHub review requested filter is the closest thing GitHub has to a review inbox, and most developers use only its weakest form: glancing at the “Review requests” count on github.com/pulls. The search syntax underneath is considerably more capable. Every qualifier in this piece is checked against GitHub’s documentation on searching issues and pull requests, and the last section is about what no query can give you: an actual sense of priority.

The short answer: Five qualifiers do the real work: review-requested:@me for everything waiting on you, user-review-requested:@me for direct personal asks, team-review-requested: for a team’s queue, reviewed-by:@me for PRs you have touched, and review:changes_requested for blocked PRs. Bookmark two or three combinations and you have a workable review inbox. What you do not get is ranking; every result looks equally urgent.

The GitHub review requested filter family, verified

The qualifiers that matter for a reviewer, straight from the docs:

review-requested:USERNAME matches pull requests where a specific person is requested for review. With @me, that person is you.
user-review-requested:@me matches pull requests that you have directly been asked to review, the personal asks as distinct from requests that reach you another way.
team-review-requested:ORG/TEAM matches PRs with a pending review request to that team, which is your queue view when reviews route through a team alias.
reviewed-by:@me matches pull requests you have reviewed, useful for finding threads you started and then lost track of.
review:none, review:required, review:approved, and review:changes_requested filter by review state, so you can find, say, every open PR sitting in changes-requested limbo.

Direct asks versus team asks

The distinction between review-requested and user-review-requested is the one worth internalizing. When someone types your username into the reviewers box, that is a personal ask with a social contract attached. When a CODEOWNERS rule or a team alias routes a PR to a group you belong to, you are one of several people who could take it. The docs define user-review-requested as the direct case, which is exactly why it deserves its own bookmark: those are the PRs where a specific human is waiting on you by name, and letting them age is how review requests quietly get lost. The team query, by contrast, is a shared pool; the failure mode there is everyone assuming someone else will pick it up. The docs also list a further variant, team-review-requested-user:USERNAME, which surfaces PRs with review requests to any team containing that user, handy for a lead who wants to see the load landing on one person through every team they belong to.

Watching the other side of the table

Two more queries round out the picture. reviewed-by:@me combined with is:open shows PRs you already reviewed that have not merged, which is where re-review requests hide after an author pushes fixes. And review:changes_requested scoped to your org surfaces every PR blocked on a rework cycle, the population most likely to be silently stuck. If your team has a turnaround expectation, these are the queries that make it inspectable; Google’s guidance on review speed argues that slow turnaround is a team-level cost, and we have covered how to formalize that in review SLAs. A query you can check is the difference between an aspiration and a practice.

Building the bookmark inbox

The practical setup takes five minutes. Create bookmarks for three URLs built on github.com/pulls or global search:

Mine, by name: is:open is:pr user-review-requested:@me
Everything waiting on me: is:open is:pr review-requested:@me, optionally scoped with org:YOURORG
In flight: is:open is:pr reviewed-by:@me for the reviews you owe a second pass

Check the first one like you check messages; sweep the other two once or twice a day. This is crude, but it beats relying on notification emails that arrive interleaved with every other kind of GitHub noise. If you want one catch-all query for everything you touch, involves:@me matches issues and PRs you created, were assigned, were mentioned in, or commented on; it is too broad to be an inbox, but it is a good weekly sweep for threads that fell through the narrower queries.

Where the filters stop helping

Now the limits. Queries scope by org, but if you work across a company org, an open source org, and personal repos, no single query gives you a clean unified view without pulling in noise from all three. More fundamentally, search returns matches, not priorities: nothing in the result list tells you which PR is release-blocking, which is a two-minute approve, and which has been waiting three days. That ranking problem is a real capacity problem, and we have written about treating review capacity as a planned resource rather than an overflow buffer. Bookmarked filters are the right floor. Just know that they hand you an unsorted pile, and the sorting is still your job. The other quiet limitation is that bookmarks are pull, not push: a query only helps when you run it. If your day fills up and the tabs stay closed, the queue ages invisibly, which is why teams that get serious about turnaround pair the queries with an explicit checking cadence, or with tooling that watches the queue for them instead of trusting willpower.

Frequently asked questions

What is the difference between review-requested and user-review-requested?

Per the GitHub docs, review-requested matches pull requests where a specific person is requested for review, while user-review-requested:@me matches pull requests you have directly been asked to review. The narrower qualifier exists to separate personal asks from requests that reach you indirectly, so use user-review-requested when you only want the PRs with your name on them.

How do I see every PR waiting on my review across repositories?

Search github.com/pulls or the global search with is:open is:pr review-requested:@me. That surfaces open pull requests where your review is requested across repositories you can access. Add org:YOURORG to scope it to one organization, and keep a second query with user-review-requested:@me for the direct, personal asks.

Can GitHub search rank review requests by urgency?

No. Search returns matches sorted by things like recency, not by how urgent, blocking, or large a review is. Every result gets equal visual weight, so a one-line docs fix sits next to a release-blocking migration. Prioritization has to come from you, from team convention, or from tooling that layers a real queue on top of the raw query results.

GitHub Code Review Shortcuts That Actually Save Time

Othman Shareef — Wed, 30 Sep 2026 08:00:00 +0000

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.

The short answer: Learn a dozen keys and the GitHub review loop gets noticeably faster: ? for the cheat sheet, T to filter changed files, C for the commits menu, I to toggle diff comments, and Cmd+Enter family keys for submitting. But shortcuts optimize navigation, not comprehension. Once the PR is large enough that the problem is understanding, not clicking, no key binding rescues the web UI.

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.

Focus: Code, one shortcut away: the chrome folds and the diff fills the window, with the shortcut printed on the exit button.

Frequently asked questions

How do I see all keyboard shortcuts on GitHub?

Type ? on almost any GitHub page and a cheat sheet appears showing the shortcuts available for that specific page. The set changes by context: the Files changed tab has review shortcuts that do not exist elsewhere, and code views have their own navigation keys. The full list lives in the GitHub docs under accessibility keyboard shortcuts.

What is the fastest way to jump to a file in a pull request?

On the Files changed tab, press T to move your cursor to the Filter changed files field, then type part of the path. In regular code views (outside a PR diff), T activates the file finder instead. Combined with the file tree on wider screens, this beats scrolling through a long diff by a wide margin.

Should review comments be submitted one at a time or batched?

Batched. Start a review with your first comment so subsequent ones stay pending and private until you submit, then send everything as one review. The author gets one coherent notification instead of a drip of emails, and you can revise earlier comments after later files change your understanding of the change.