A nit, short for nitpick, is a minor comment in a code review: a variable name, a typo in a comment, a slightly simpler way to write a line. Reviewers prefix it with “nit:” to say it is not a blocker. “Approved with nits” means the reviewer approved the change and left some of those small notes alongside.
The convention exists so authors can tell the difference between “this needs to change” and “I would have done this differently.” Some teams formalize it with a scheme like Conventional Comments, which uses labels such as nitpick, suggestion and issue, with a (non-blocking) tag where it applies.
When you receive an approval with nits, the usual etiquette is to address the ones you agree with and merge without asking for another review. If you skip one, a short reply saying so is enough. On GitHub, nits written as suggested changes can be committed straight from the review with one click, which removes most of the friction.
When you give nits, keep the count proportionate. Five nits on a ten-line change can read as a rejection even with an approval attached. If the same nit comes up every week, it belongs in a linter or formatter rule, not in a human review. Tools like ESLint, Prettier, Ruff or gofmt settle naming and formatting questions so reviewers can spend attention on behavior.
Nits are a sign of a careful reviewer. They should not be the only thing the reviewer looked at.
The piece says “APPROVED WITH NITS.” The comments about naming are implied.
In the wild
Approved with nits. nit: rename `data` to `invoices` in the loader. Fine to merge after.
