5 exercises — each question asks whether a given expression is a natural English collocation used by native speakers.
How to approach True or False collocations
Ask yourself: would a native speaker say this naturally, or does it sound translated?
Check the verb: many errors come from using a generic verb (do/make) instead of the precise one
Some expressions sound almost right — the difference is often one word
0 / 5 completed
1 / 5
True or False: 'squash commits' is a real Git collocation — it means to combine multiple commits into a single one.
TRUE — "squash commits" is a legitimate and widely-used Git collocation.
When working with Git, squashing means collapsing several commits into one cleaner commit, usually before merging a feature branch.
git rebase -i HEAD~3 — interactive rebase lets you mark commits as squash or fixup to combine them
squash and merge — the GitHub/GitLab button that merges a PR while squashing all branch commits into one
fixup commit — similar to squash but discards the commit message
Related collocations:
squash commits ✅
squash a PR ✅
squash and merge ✅
fixup commit ✅
Contrast: rebase (rewrite commit history by moving commits on top of another base), merge (combine branches, preserving history). Squash is a destructive operation — it rewrites history — so it is typically used on feature branches before they land on main.
2 / 5
True or False: 'do a merge' is the natural English expression when combining branches in Git.
FALSE — "do a merge" is not the natural collocation in professional developer English.
"Do" is a generic verb that rarely collocates precisely with technical Git actions. Instead, English uses the specific verb merge directly:
merge a branch ✅ — "I will merge the feature branch into main."
merge a PR ✅ — "She merged the pull request after the review."
merge into main ✅ — directional phrasing
run a git merge ✅ — when referring to the command explicitly
Why not "do a merge"? In English, highly specific technical actions get their own precise verb. Compare: you deploy (not "do a deployment"), you rebase (not "do a rebase"), you merge (not "do a merge").
Pattern to avoid: "do a merge" ❌, "make a merge" ❌, "do a rebase" ❌. These sound like direct translations from languages where one generic verb covers all actions.
3 / 5
True or False: 'rebase on top of' is the correct English phrase when describing a rebase operation — e.g., "I rebased my branch on top of main."
TRUE — "rebase on top of" is natural and widely used in developer conversation.
Both "rebase on top of" and "rebase onto" are valid, but they appear in different contexts:
rebase on top of ✅ — conversational: "I rebased my feature branch on top of main so there are no conflicts."
rebase onto ✅ — also natural, slightly more concise: "Rebase your work onto the latest commit."
git rebase --onto — the CLI flag uses --onto for advanced three-point rebasing operations
The phrase "on top of" is an idiomatic prepositional phrase meaning "above and directly resting on." In Git context it means: your commits are now placed after the latest commit of the target branch.
Both forms are acceptable in pull request comments, documentation, and team communication:
"Can you rebase this branch on top of the latest main?" ✅
"Rebase onto main before merging." ✅
4 / 5
True or False: 'push the commits' is a natural Git collocation — for example, "push the commits to the remote branch."
TRUE — "push commits" and "push to remote" are core Git collocations.
"Push" is a fundamental Git verb with several natural collocations:
push commits ✅ — "Push the commits before the deadline."
push to remote ✅ — "I pushed to remote; check the CI status."
push to origin ✅ — using the remote name: git push origin main
push to main ✅ — push to a specific branch
push a branch ✅ — "Push your branch so I can review it."
force-push ✅ — git push --force, used to overwrite remote history
push upstream ✅ — push to the configured upstream tracking branch
Contrast with related operations:
pull = fetch + merge (download and integrate changes)
fetch = download changes without merging
"Upload commits" ❌ and "send the commits" ❌ are not natural — "push" is the precise technical term that all Git documentation and developer communication uses.
5 / 5
True or False: 'make a pull request' is as natural as 'open a pull request' or 'create a pull request' in professional developer English.
FALSE (nuanced) — "make a pull request" is grammatically possible but less natural than the preferred alternatives.
GitHub's own UI uses "Open a pull request" as the button label — this is the most widely recognised phrasing. Here is the full range:
open a PR ✅ — the most common in GitHub culture: "I opened a PR for the new feature."
create a PR ✅ — also natural and widely used
submit a PR ✅ — implies sending for review
raise a PR ✅ — British English preference: "Raise a PR against main."
make a PR ⚠️ — grammatically acceptable but marks non-native usage
Why does "make" sound off? "Make" collocates well with things you produce from scratch (make a decision, make a mistake, make dinner). Pull requests are opened or created in a workflow context — the metaphor is about initiating a review process, not manufacturing something.
Rule of thumb: When a platform's UI uses a specific verb ("Open a pull request"), adopt that verb in your communication.