Nit meaning in code review, plus PTAL and other terms

In code review, a nit (short for nitpick) is a minor comment about something the reviewer would like changed but won't hold up the merge for, like a variable name, a typo or the order of imports. Reviewers start the comment with "Nit:" so the author can tell it apart from required changes.

Google's guide to review comments defines a nit as "a minor thing. Technically you should do it, but it won't hugely impact things." Outside code review, nitpicking means fussing over details that don't matter. Merriam-Webster defines nit-picking as "minute and usually unjustified criticism" and dates its first known use to 1951. The word comes from picking nits, the eggs of lice, out of someone's hair.

For how the review process works as a whole, start with what code review is and how it works.

What nit means in a code review

Meaning: A nit is the smallest kind of review comment. It covers polish, such as naming, typos, comment wording or formatting the linter missed. The label matters because, as Google's guide puts it, "without comment labels, authors may interpret all comments as mandatory."

Teams don't fully agree on whether a nit is optional. Google says "technically you should do it." Conventional Comments calls nitpicks "trivial preference-based requests" that "should be non-blocking by nature." Bitcoin Core's contributing guide calls a nit "a trivial, often non-blocking issue." A workable default for authors: fix the nits that take a minute, and reply to the ones you disagree with.

Example comment: "Nit: cnt could be retryCount. It took me a second to see what this loop counts."

When to use it: For anything that would make the code a little better without changing how it behaves. Don't use it for bugs, missing tests or security problems. Those block the merge, so say so. If you leave the same nit on every pull request, make it a lint rule instead. Google's reviewer guide is direct about this: "Don't block CLs from being submitted based only on personal style preferences." (A CL, or changelist, is Google's word for a change under review.)

If nits are all that's left, approve and leave them for the author. Google calls this LGTM with comments. Our guide to code review best practices covers how to keep minor comments from slowing reviews down.

Google's guide pairs Nit with two other labels:

• Optional (or Consider): "I think this may be a good idea, but it's not strictly required."

• FYI: "I don't expect you to do this in this CL, but you may find this interesting to think about for the future."

Terms for asking for a review

PTAL

Meaning: "Please take a look." The Go project's code review wiki lists it with LGTM and SGTM as standard reviewer parlance. It asks for a review, either the first one or another pass after you've pushed changes.

Example comment: "PTAL. Addressed everything except the cache TTL, and I replied inline on that one."

When to use it: When you want someone's eyes on the change now. Pair it with a review request on the platform, since a comment alone is easy to miss.

WIP

Meaning: "Work in progress." The change isn't ready for review or merge.

Example comment: "Still WIP. The API layer is done, but don't review the migration yet."

When to use it: When you've shared unfinished work and want to set expectations. Prefer your platform's draft state over a "WIP" prefix in the title, because a draft can't be merged by accident (see the next entry). The Go project uses "DO NOT SUBMIT" in the commit message to block submission for the same reason.

Draft pull request

Meaning: A pull request that's open but marked as not ready. On GitHub, draft pull requests "cannot be merged, and code owners are not automatically requested to review them." You mark the pull request ready for review when it's done. GitLab's draft merge requests work the same way: they can't merge until you remove the Draft flag. You can set it with a Draft: prefix in the title or the /draft quick action, and clear it with /ready.

Example comment: "Opening as a draft so CI runs on the new config. Not ready for review yet."

When to use it: Open a draft early when you want CI results, want to show the direction, or have several dependent changes in flight. Mark it ready when you'd be happy for someone to approve it.

RFC

Meaning: "Request for comments." The author wants feedback on the approach, not a line-by-line review. The Linux kernel's patch guidelines list "RFC" as a subject tag "to indicate a request for comments," as in [PATCH RFC]. The term shares its name with the internet's RFC series, which began with RFC 1 in 1969.

Example comment: "RFC: this moves rate limiting from each service into the gateway. Looking for feedback on the approach before I write the tests."

When to use it: Before you spend real time on an approach that others might reject. Open it as a draft so nobody merges it, and say what kind of feedback you want.

Terms for agreeing and approving

LGTM

Meaning: "Looks good to me." Google's engineering practices guide defines it as "what a code reviewer says when approving a CL." Our post on what LGTM means covers where it's used and when an LGTM is a rubber stamp.

Example comment: "LGTM. Ran the migration locally and checked the rollback. One nit inline."

When to use it: When you've reviewed the change and you're fine with it merging. On GitHub, typing LGTM in a comment isn't an approval. Only an Approve review counts toward required approvals.

SGTM

Meaning: "Sounds good to me." Agreement with a plan, a proposal or an answer, rather than approval of code. The Go wiki lists it next to LGTM.

Example comment: "SGTM. Let's keep the old endpoint until the mobile release ships, then delete it."

When to use it: When someone proposes how to resolve a comment or describes a follow-up, and you agree. It closes the discussion without suggesting you've re-reviewed the code.

+1

Meaning: Agreement. In a comment thread, "+1" means "I agree with the comment above." Some systems turn it into a formal vote:

• In Gerrit, a Code-Review +1 means "Looks good to me, but someone else must approve," and a +2 means "Looks good to me, approved."

• In Apache Software Foundation projects, votes run from -1 to +1. A -1 from a qualified voter on a code change is a veto, and it "cannot be overruled nor overridden by anyone."

Example comment: "+1 to Priya's point about the timeout. 30 seconds will hold connections open during deploys."

When to use it: When you agree and have nothing new to add. If you do have a reason, give it. A bare +1 adds weight to an argument without adding information.

ACK and NACK

Meaning: ACK (from acknowledge) is approval, and NACK is an objection. You'll see them in the Linux kernel, Bitcoin Core and other open source projects.

• In the kernel, an Acked-by: tag records that someone responsible for the affected code "has at least reviewed the patch and has indicated acceptance." It's less formal than Reviewed-by:, and it may cover only the part of a patch that touches that person's code.

• Bitcoin Core's contributing guide splits approval into stages. "Concept ACK" means you agree with the goal, "Approach ACK" means you also agree with the approach, and a code review starts with "ACK" plus the commit it covers and a description of how you reviewed it. Objections have a rule: "A NACK needs to include a rationale why the change is not worthwhile."

Example comment: "ACK 3f2a9c1. Read the full diff and ran the functional tests locally. Didn't test on Windows."

When to use it: In projects that already use them. Everywhere else, the platform's Approve and Request changes options say the same thing, and merge rules can enforce them.

Approve, request changes and comment

Meaning: These are the three decisions a GitHub pull request review can end with:

• Approve "signals that the changes are ready to merge."

• Request changes "flags feedback that the author should address before merging."

• Comment "leaves general feedback without explicitly approving or requesting changes."

When branch protection or a ruleset requires approving reviews, the approvals have to come from people with write permissions or from designated code owners. Under a ruleset, a reviewer who chooses Request changes must approve before the pull request can be merged, and if that reviewer isn't available, anyone with write permissions can dismiss the blocking review. Branch protection applies the same rule when the reviewer has admin permissions. GitLab merge requests have an Approve button and an /approve quick action.

Example comment: With Approve, "LGTM, one optional comment inline." With Request changes, "Requesting changes for the missing permission check in deleteProject. The rest looks good."

When to use it: Approve when you'd be fine with the change merging as it is, or with only nits left. Request changes when something must be fixed first, and say exactly what. Comment when you have questions or reviewed only part of the change. Our code review checklist lists what to check before you choose.

An approval says you read the change. That matters more when a coding agent wrote it, because the review may be the first time a person reads every line. Bug Bench, our public benchmark, counts a bug when a developer upvotes a cubic review finding on AI-written code or an AI coding agent addresses it. Every one of the 7 models in its current ranking has counted bugs. AI-written code also breaks in its own ways, covered in why AI code fails differently. AI code review can take the first pass on that code, and a person still gives the approval.

Terms for labeling comments

Blocking and non-blocking

Meaning: A blocking comment must be resolved before the change merges. A non-blocking comment is the author's call. Conventional Comments marks this with decorations. A "(blocking)" comment "should prevent the subject under review from being accepted, until it is resolved," and a "(non-blocking)" comment "should not prevent" it. A third decoration, "(if-minor)", asks the author to make the change only if it turns out to be small.

Example comment: "issue (blocking): this retry loop has no upper bound, so an outage in the payment API will tie up a worker indefinitely." Or: "suggestion (non-blocking): a guard clause here would remove a level of nesting."

When to use it: Whenever your team's default isn't obvious. Label the exceptions to your default. If most comments are optional, mark the blocking ones. If most are required, mark the non-blocking ones.

Suggestion

Meaning: As a label, a suggestion proposes an improvement, and Conventional Comments asks you to be "explicit and clear on what is being suggested and why it is an improvement." On GitHub, a suggestion is also a feature. The reviewer writes replacement code in a suggestion block, and the author can apply it with Commit suggestion or add several to a batch that becomes one commit. Everyone whose suggestion is in that commit is listed as a co-author.

Example comment: In a GitHub review comment, the explanation goes above the suggestion block:

When to use it: When you know the exact fix and it's a few lines. For bigger changes, describe the problem and let the author choose the fix. Google's guide notes that "it is the developer's responsibility to fix a CL, not the reviewer's."

Conventional Comments labels

Meaning: Conventional Comments is a format for review comments: a label, optional decorations in parentheses, then the subject, as in label (decorations): subject. Supporting detail goes on the lines below. These are the labels it recommends:

It also offers typo, polish and quibble. A quibble is "very much like nitpick:, except it does not conjure up images of lice and animal hygiene practices."

Example comment: "question (non-blocking): can this channel be closed by the time we read from it, or is that impossible here?"

When to use it: When comments on your team often get misread, or when you want comments that tools can parse. The project lists Conventional Commits, a format for commit messages, as prior art. The two names are easy to mix up.

Other shorthand

• CL, PR and MR: a change under review. CL (changelist) is Google's term, pull request is GitHub's, and merge request is GitLab's.

• s/foo/bar/: "please replace foo with bar," in sed syntax. The Go wiki adds that s/foo/bar/g means replace it throughout the whole change.

Summary table

FAQ

What does nitpick mean?

To nitpick is to criticize small, unimportant details. Merriam-Webster defines nit-picking as "minute and usually unjustified criticism." In code review, a nitpick (or nit) is a neutral label for a minor comment that the author can usually take or leave.

What is a nit on GitHub?

It's an ordinary review comment that starts with "Nit:". GitHub reviews end in Comment, Approve or Request changes, so the prefix is what tells the author the point is minor, and you can approve with nits still open. If the branch requires conversation resolution before merging, though, every comment has to be resolved first, nits included.

Is nitpick a bad word?

No. It's informal, but it isn't offensive. Calling a person a nitpicker is a criticism, while labeling your own comment "Nit:" is polite, because it tells the author the point is minor. Conventional Comments offers "quibble" for anyone who'd rather avoid the lice.

What is another word for nitpick?

Quibble is a close synonym, and Conventional Comments offers quibble: as an alternative to nitpick:. For a suggestion that goes beyond polish, Google's guide uses "Optional" or "Consider," and Conventional Comments has polish:.

What does PTAL mean?

PTAL means "please take a look." Authors use it to ask for a first review, or for another look after pushing changes. Outside software, PTAL also stands for public transport accessibility level, a measure used in UK transport planning.