5 exercises on the verb collocations developers use during the pull request review process. Choose the right verb for the right context.
Key verb patterns
request a review — the formal term (GitHub button label), not "ask for"
address the feedback — act on reviewer comments (not "fix" or "answer")
push an update — send new commits to the remote branch
re-request a review — prompt the reviewer to look again after changes
squash and merge — combine commits and integrate into main
0 / 5 completed
1 / 5
After opening a pull request, a developer wants a specific teammate to look at their code. Which phrase is the most precise and professional?
Request a review — the professional collocation and GitHub's own label:
Request a review is both the natural English collocation and the exact label on the GitHub button ("Request reviewers"). "Request" is formal and professional — it implies a deliberate, directed ask to a specific person or team.
Why not the others?
ask for a review — correct but informal; fine in spoken conversation ("Can you ask Sarah for a review?") but not the technical term used in the UI or in written communication
demand a review — sounds aggressive and is not a collocation in this context
need a review — expresses a state, not an action
Review workflow collocations:
request a review / assign a reviewer / ping a reviewer
the PR is awaiting review / waiting on reviews
I've requested a review from the platform team
re-request a review (after addressing feedback)
In GitHub: open PR → Reviewers panel (right sidebar) → click the gear → select a person → "Request" button appears. In conversation: "I've requested a review from Ana — could you also take a look when you get a chance?"
2 / 5
A reviewer leaves several comments on a pull request. The PR author then works through each comment and makes the necessary code changes. Which phrase describes this?
Address the feedback — attend to and deal with reviewer comments:
Address the feedback is the correct professional collocation. "Address" means to attend to something and take appropriate action — it implies both understanding the comment and responding appropriately, whether through code changes, clarification, or reasoned pushback.
Why not the others?
reply to the feedback — "reply" only covers writing a written response, not making the actual code changes that the comment requires
fix the feedback — grammatically wrong in this context; you fix bugs and code, not feedback
answer the feedback — sounds non-native; "answer" collocates with questions, calls, and emails, not code review feedback
Common address-feedback phrases in pull requests:
"I've addressed all the feedback in this commit."
"Addressing your comments in the latest push."
"Left a comment explaining why I didn't address this one — happy to discuss."
"All review comments have been addressed — re-requesting review."
This is one of the most important collocations for developers working in English-speaking teams.
3 / 5
After addressing the reviewer's comments and committing the changes, the developer needs to make the updated code available on the remote branch. Which phrase is most natural?
Push an update — the git collocation for sending new commits to the remote branch:
Push an update is the natural collocation in git-based workflows. After addressing review comments and creating new commits, you push those commits to the remote branch — this automatically updates the open pull request with the new changes.
Why not the others?
send an update — generic English, not used in git vocabulary; "send" works for emails and messages
submit an update — "submit" collocates with forms, job applications, and assignments; not git pushes
upload an update — generic file-transfer vocabulary; git uses "push" not "upload"
Push collocations in the review cycle context:
push an update / push a fix / push the changes
"I pushed a fix for the edge case you mentioned."
"Just pushed an update addressing your comments — take another look when you get a chance."
After pushing new changes to address a reviewer's comments, the PR author wants the reviewer to look at the code again. Which is the correct phrase?
Re-request a review — the precise term and GitHub button label:
Re-request a review is both the correct English collocation and the exact phrase GitHub uses for its button. When a reviewer leaves comments, GitHub automatically dismisses their review approval. After pushing changes, the PR author explicitly re-requests to prompt the reviewer to look again.
Why not the others?
ask for review again — understood but informal; not the technical term
re-do the review — this describes the reviewer's action (they redo the review), not the author's action (requesting it)
remind the reviewer — this is an informal action (send a Slack message), not the formal PR workflow step
The full re-request workflow:
Author pushes changes addressing feedback
Author re-requests a review (GitHub: click the circular arrow icon next to the reviewer's name)
Reviewer receives a notification that their review has been re-requested
Reviewer looks at the diff since their last review and approves or requests further changes
In a Slack message accompanying this action: "Pushed the changes — re-requested your review. Let me know if anything else needs attention."
5 / 5
The pull request has been approved and is ready to be integrated into the main branch. Which phrase uses the correct collocations for the final merge step?
Squash and merge — a specific GitHub merge strategy:
Squash and merge is a specific, named GitHub merge strategy that combines all commits in the PR into a single commit before merging into the target branch. It keeps the main branch history clean and readable.
The three GitHub merge strategies:
Create a merge commit — preserves all individual commits from the PR, adds a merge commit; full history preserved
Squash and merge — combines all PR commits into one commit; cleaner history, loses individual commit granularity
Rebase and merge — replays each PR commit on top of main without a merge commit; linear history
Why not the others?
publish and integrate — not a collocation in git or GitHub vocabulary
commit and save — "save" is not used in this context; also, you've already committed before merging
accept and close — "accept" is not used for PRs; you "approve" a PR, and "close" means abandoning without merging
In team discussion: "Should we squash and merge this, or do we want to preserve the commit history?"