5 exercises — read the scenario and answer questions about which collocations fit the context and why.
Scenario: The reviewer leaves a nit comment about variable naming, a blocking comment about a security vulnerability, writes LGTM after the author addresses the feedback, and asks the author to squash commits before merging.
Author actions: address the feedback, squash commits
Review outcomes: approve, request changes, merge
0 / 5 completed
1 / 5
"A nit comment" — what is a "nit" in code review?
"Nit" — the collocation for minor code review feedback.
A nit (short for nitpick) is a small, low-priority suggestion that the reviewer considers optional or a matter of preference. Common nit subjects:
Variable naming: "nit: res could be response for clarity"
Formatting: "nit: trailing whitespace on line 42"
Comment style: "nit: missing full stop in docstring"
How to use it: prefix your comment with nit: to signal it is non-blocking. The author can choose to address it or not.
The spectrum of comment severity in code review:
nit: — minor, optional
suggestion: — consider this improvement
question: — I want to understand this
blocking: / must fix: — required before merge
Knowing this vocabulary lets you communicate feedback precisely without ambiguity about what is required vs. optional.
2 / 5
"A blocking comment" — what does "blocking" mean here?
"Blocking comment" — a comment that gates the merge.
In code review culture, blocking means the PR cannot proceed until the issue is addressed. The term comes from the concept of blocking progress — like a blocker in Scrum.
Breaking changes — API changes without versioning, missing migrations
Missing tests — critical paths without coverage
On GitHub, a reviewer formally blocks a PR by choosing Request Changes (vs. Comment or Approve). The PR is blocked until the reviewer dismisses their review or approves.
Collocations: leave a blocking comment, raise a blocking issue, mark as blocking, unblock a PR (resolve the issue and approve). The antonym is a non-blocking comment or nit.
3 / 5
"LGTM" — this acronym means:
LGTM = Looks Good To Me — the universal code review approval signal.
LGTM is one of the most common acronyms in pull request culture. When a reviewer writes LGTM, it means they have reviewed the code and are satisfied — it is their informal approval signal, often paired with the formal GitHub "Approve" action.
Usage examples:
"LGTM! Nice clean implementation."
"LGTM aside from the nit on line 23."
"Two LGTMs required before merging." (team policy)
Related acronyms in code review culture:
WIP — Work In Progress (draft PR, not ready for review)
RFC — Request For Comments (early feedback wanted)
PTAL — Please Take A Look (requesting review)
ACK — Acknowledged / Approved (common in open-source)
NACK — Negative Acknowledgement / Not Approved
These acronyms originate in open-source mailing list culture (Linux kernel, Apache) and have spread to all modern engineering teams.
4 / 5
"Addresses the feedback" — which explanation is correct?
"Address feedback" — the collocation for responding to review comments.
The verb address here means to deal with, respond to, and resolve. It is the natural and expected verb with "feedback" in professional English:
"I've addressed all the feedback — please take another look."
"Addressing your comment in this commit."
"Can you address the blocking comment before I re-review?"
What addressing feedback looks like in practice:
Making the requested code change and pushing a new commit
Replying to the comment explaining why you disagree or chose a different approach
Marking the comment as resolved on GitHub
Key collocations in this workflow:
address the feedback ✅ — most natural
resolve the comments ✅
respond to the feedback ✅
push a fix ✅ (for code changes)
request a re-review ✅ (after addressing everything)
Avoid: "do the feedback", "make the feedback", "fix the feedback" (these collocations are non-native).
5 / 5
"Squash commits" — what does squashing mean?
"Squash commits" — the git history cleanup collocation.
During feature development, developers often create many small commits: "fix typo", "WIP", "actually fix it", "remove console.log". Before merging, squashing combines all of these into one clean, meaningful commit.
Why squash?
Keeps git log on main clean and readable
One commit per feature/fix makes git bisect more useful
Easier to revert a single atomic commit
Team policy: many teams require squash before merge
How to squash:
git rebase -i HEAD~N — interactive rebase, mark commits as squash
GitHub's "Squash and merge" button — does it automatically
Related git collocations:
squash and merge ✅ (GitHub merge strategy)
rebase and merge ✅ (keeps linear history)
create a merge commit ✅ (preserves branch structure)