5 exercises on the language of approving and merging pull requests — the sign-off shorthands and merge-strategy collocations developers use every day.
Key patterns
LGTM → "Looks Good To Me", informal approval
approve with comments → green-light plus optional notes
squash and merge / rebase and merge → merge strategies
hold off merging → deliberately wait before merge
get a second pair of eyes / sign off on it → extra review & approval
0 / 5 completed
1 / 5
A reviewer is happy with a PR and wants to give the quickest, most common informal sign-off in a comment. What do they write?
LGTM — the classic informal approval:
LGTM stands for "Looks Good To Me" and is the most widely used shorthand for signalling approval in a comment.
"LGTM 🚀 — nice work."
"LGTM once CI passes."
"LGTM with one nit — feel free to ignore."
Related approval shorthands:
SGTM — "Sounds Good To Me" (for proposals/decisions).
+1 — agreement / approval.
ship it — enthusiastic go-ahead to merge and deploy.
👍 / ✅ — emoji approval.
Why the distractors fail:GLHF, AFAIK, and WIP are real acronyms but mean entirely different things — none signals approval. Note that an informal "LGTM" comment is separate from clicking GitHub's formal Approve button; many teams require the formal approval too.
2 / 5
A reviewer thinks the code is fine to merge but wants to leave a couple of small remarks the author can handle without re-review. Which phrase captures this?
Approve with comments — green-light plus optional notes:
To approve with comments means you formally approve the PR (it can merge) while leaving non-blocking suggestions the author may address at their discretion.
"Approving with comments — two nits, your call."
"LGTM. Approved with minor comments."
"Approve, but please address the typo before merging."
Contrast the three GitHub verdicts:
Approve — good to merge.
Comment — feedback only, no verdict.
Request changes — blocks the merge.
Why the others fail: "reject with comments" contradicts the intent to merge; "approve and block" is self-contradictory; and "comment without approving forever" leaves the PR in limbo. "Approve with comments" is the precise, friendly way to unblock a teammate while still flagging nits.
3 / 5
A team keeps a clean history by combining all of a PR's commits into a single commit when integrating. What is this merge strategy called?
Squash and merge — one tidy commit per PR:
"Squash and merge" combines all the commits on a branch into a single commit before merging it into the base branch — giving a clean, one-commit-per-feature history.
"We squash and merge so main stays readable."
"Please squash the WIP commits before merging."
"Squashed and merged — thanks!"
The three GitHub merge strategies:
create a merge commit — preserves every commit plus a merge commit.
squash and merge — collapses commits into one.
rebase and merge — replays commits linearly, no merge commit.
Why the distractors fail:cherry-pick copies an individual commit; stash shelves uncommitted work; "fast-forward" advances a pointer without squashing. The strategy that combines commits into one is specifically squash and merge.
4 / 5
A reviewer wants the commits kept as-is but laid out in a straight line on top of main, with no merge commit. Which strategy do they pick, and which related phrase means "wait before merging"?
Rebase and merge & hold off merging:
"Rebase and merge" replays each commit from the PR on top of the base branch, producing a linear history with no merge commit — while keeping the individual commits intact (unlike squash).
"We rebase and merge to keep history linear."
"All commits preserved, just rebased onto main."
To hold off (on) merging means to deliberately wait before merging.
"Let's hold off merging until the release is cut."
"Hold off — QA hasn't signed off yet."
Strategy contrast:merge commit keeps history with an explicit merge node; squash collapses to one commit; rebase and merge gives linear history with commits preserved. "Hold off merging" is the natural phrasal verb for pausing — clearer than "hold up", which more often means delay/obstruct in a frustrated sense.
5 / 5
A change touches sensitive auth code, so the author wants another reviewer to look before merge, and afterwards a lead formally approves it. Which two collocations are natural?
Get a second pair of eyes & sign off on it:
"Get a second pair of eyes" means asking another person to review — valuable for risky or sensitive code.
"This touches auth — let's get a second pair of eyes on it."
"Could you be a second pair of eyes on this PR?"
To sign off (on something) means to give formal approval.
"The lead signed off on the release."
"Once QA signs off, we can merge."
"Signed off ✅ — ready to ship."
Related approval phrases:give the green light, give the go-ahead, approve, rubber-stamp (a quick, sometimes too-casual approval).
Why the distractors fail: "second set of hands" means extra help with work, not review; "sign in" means log in; "sign away" means relinquish rights. The idioms for reviewing and approving are specifically a second pair of eyes and sign off on.