1 / 5
A reviewer is happy with the pull request and lets it merge. They ___ the PR.
-
-
-
-
Approve a PR is the standard term for signing off on a pull request.
- approve a PR / a change
- The opposite is to block a PR (prevent it merging)
"Okay off" and "pass up" aren't standard. Example:
"Looks good — I'll approve the PR."
2 / 5
A reviewer finds a serious problem and prevents the PR from being merged. They ___ it.
-
-
-
-
Block a PR means putting a blocking review on it so it can't merge until resolved.
- block a PR / a merge
- Often paired with request changes
"Bar off" and "stall out" aren't the collocation. Example:
"I'm blocking this until the security issue is fixed."
3 / 5
A reviewer wants edits before approving. In GitHub terms, they ___.
-
-
-
-
Request changes is the formal review action asking the author to make edits before approval.
- request changes (on a PR)
- Blocks the merge until addressed and re-reviewed
"Ask edits off" and "demand fixes up" aren't standard. Example:
"I requested changes — the tests need updating."
4 / 5
A reviewer leaves a minor, optional comment (e.g. a style preference). This kind of comment is a ___.
-
-
-
-
A
nit (from "nitpick") is a small, non-blocking review comment, often prefixed
nit:.
- a nit / nitpick — minor, optional feedback
- Signals "feel free to ignore"
"Ding off" and "niggle up" aren't standard. Example:
"Nit: prefer const here, but not blocking."
5 / 5
After making the requested edits, the author ___ the reviewer's feedback and the reviewer says ___.
-
-
-
-
Address feedback means responding to and resolving review comments;
LGTM ("Looks Good To Me") is the common approval shorthand.
- address feedback / comments
- LGTM — informal sign-off
The other options aren't standard review jargon. Example:
"I've addressed all the comments." / "LGTM, merging."