5 exercises on the language of pull requests and code reviews — the accurate verbs and phrases every developer needs to give and respond to feedback professionally.
Core code review vocabulary patterns
approve a PR → formally mark it ready to merge
request changes → formally block the merge
nit → minor, optional comment (from "nitpick")
address feedback → make the requested changes
merge a PR → integrate the branch into main
LGTM → informal approval ("Looks Good To Me")
0 / 5 completed
1 / 5
A senior developer opens a pull request. After reading the code, they agree that it looks good and is ready to merge. What is the standard action and phrase in a GitHub-style code review?
Approve — the standard code review action:
In pull request workflows (GitHub, GitLab, Bitbucket), the formal review actions are:
Approve — the reviewer agrees the code is ready to merge. GitHub shows a green check mark. Many teams require one or two approvals before a PR can be merged.
"I've approved the PR."
"The PR has two approvals — it's ready to merge."
"Can you approve my changes?"
Request changes — the reviewer has blocking feedback. The PR cannot be merged until changes are made and the reviewer re-reviews.
"I requested changes — there's a logic error in the auth middleware."
Comment — leave feedback without formally approving or blocking.
"I left a comment but didn't block it — the suggestions are optional."
Common informal phrases for approval:
LGTM — "Looks Good To Me" — the most common informal approval signal
"Approved ✓"
"Looks good, merging." — reviewer merges the PR themselves
"Good work! Approved."
2 / 5
A reviewer finds a small, non-critical issue — a minor style inconsistency in a variable name that doesn't affect functionality. How would they typically label this in a comment?
Nit — the essential code review vocabulary for minor feedback:
A nit (short for "nitpick") is a minor, often optional comment that does not block the PR from merging. It signals: "I noticed this, but it's your call whether to fix it now."
Using "nit" in practice:
"nit: this variable could be renamed `isLoading` for clarity."
"nit: extra blank line here — can be cleaned up."
"Nit, feel free to ignore: the comment could be more descriptive."
Severity levels in code review comments:
nit / nitpick — cosmetic, optional, non-blocking
suggestion — recommended but not required to merge
question — asking for clarification: "Why is this using X instead of Y?"
blocker / must-fix — must be resolved before the PR can merge
Modern tools (e.g. GitLab) support formal severity labels on comments.
In sentences:
"Just a few nits, otherwise LGTM."
"Approved with minor nits — feel free to address before merging."
3 / 5
During a pull request review, a developer writes: "We should ___ the PR once the CI pipeline turns green and the feedback is resolved." Which verb is correct?
Merge — the standard PR lifecycle verb:
In pull request workflows, merging the PR integrates the feature branch into the target branch (usually `main` or `develop`).
Key PR lifecycle verbs:
open / create a PR — start the review process
review a PR — read the code and leave feedback
approve / request changes — formal review actions
address feedback — make the requested changes
resolve a comment — mark it as handled (in GitHub/GitLab)
merge a PR — integrate the branch into `main`
close a PR (without merging) — reject or abandon it
revert a PR — undo the merge after it's been completed
Merge strategies (common vocabulary):
merge commit — creates a merge commit preserving full branch history
squash and merge — combines all commits into one before merging
rebase and merge — replays commits on top of the base branch, linear history
Common phrases:
"This PR is ready to merge."
"Merging now — thanks for the review!"
"Don't merge until the docs are updated."
4 / 5
A developer submits a PR and gets feedback from a reviewer. The reviewer asks for several changes. After making them, the developer writes a comment. What is the most natural professional phrase?
Address feedback — the essential response phrase in code review:
"Address feedback" is one of the most natural professional expressions for responding to code review comments. It means: I have dealt with / responded to the points raised.
Related expressions:
"I've addressed all the comments."
"The feedback has been addressed."
"I addressed the main concerns and left a note about X."
"Addressed — I refactored the function as suggested."
Companion verbs used in review responses:
resolve a comment — mark it as handled in GitHub/GitLab: "I've resolved the thread."
fix — for bugs and errors: "Fixed the null check."
update — for documentation or clarifications: "Updated the README."
revert — undo a change if the approach was wrong
agree / disagree — respond to suggestions: "Agreed — I've renamed it. / I disagree with this change because…"
Requesting a re-review:
"Ready for re-review."
"Please take another look when you have a moment."
"Re-requesting review after addressing the feedback."
5 / 5
A tech lead reviews a PR and discovers that a critical security vulnerability was introduced. They need to stop the PR from being merged until the issue is fixed. What phrase do they use?
Blocking a PR — the vocabulary of stopping a merge:
When a reviewer has a critical issue, they have two related things to do: perform the formal review action AND communicate the severity clearly.
The formal action: In GitHub, selecting "Request changes" formally prevents the PR from being merged until the reviewer approves again. This is the mechanism.
The vocabulary of blocking:
"This is a blocker." — a noun: an issue that blocks progress
"I'm blocking this." — a verb: actively preventing the merge
"Blocking issue: the connection pool is not thread-safe."
"Must-fix before merge: the token is logged in plaintext."
Severity label vocabulary in PR comments:
nit — cosmetic, optional
suggestion — recommended, non-blocking
question — clarification requested
blocker — must be resolved before merging
SECURITY / CRITICAL — urgent, potentially breaking or dangerous
Template for a blocking review comment: "Blocker: [what is wrong]. [Why it matters]. [What to do instead]."
"Blocker: User input is interpolated directly into the SQL query — this is a SQL injection vulnerability (OWASP A03:2021). Use parameterised queries instead."