A team policy states: "Always squash commits before merging a PR."
What does squashing commits do to the Git history?
Squash merge strategies:
Strategy
Main branch history
Feature commits
Squash merge
1 commit per feature (clean)
Lost (compressed into one)
Merge commit
Merge commit + all feature commits
Preserved with merge bubble
Rebase merge
All feature commits (linear)
Preserved, new SHAs
Key vocabulary: squash merge, atomic commit, clean history, squash vs. merge commit vs. rebase.
2 / 10
A code review uses a merge commit strategy and the commit graph shows a "merge bubble".
What is a merge bubble and when is it preferred?
Merge commit (merge bubble) — preserving full context:
Feature
Detail
Two parents
Merge commit references both the branch tip and main tip
Non-linear history
Shows branch diverge and merge points visually
Preserve when
Audit trail matters; large reviewed features; release tracking
Compare: rebase = linear history (no bubble), squash = linear + compressed. Key vocabulary: merge commit, two parents, non-linear history, audit trail preservation.
3 / 10
A developer runs git rebase main on their feature branch.
What does rebasing onto main do?
git rebase — re-writing branch history onto a new base:
Before rebase
After rebase
Branch base: old main commit
Branch base: current main tip
Non-linear graph
Linear graph, enable fast-forward merge
Old commit SHAs
New commit SHAs (history rewritten)
Critical rule: NEVER rebase public/shared branches — it rewrites history and breaks collaborators. git push --force-with-lease needed after rebase. Key vocabulary: linear history, commit SHA rewrite, force-push after rebase, don't rebase public branches.
4 / 10
A code review comment says: "The merge was a fast-forward."
What conditions allow a fast-forward merge?
Fast-forward merge — possible only when no divergence exists:
Situation
Merge type needed
main has NO new commits since branch point
Fast-forward possible (pointer moves forward)
main HAS new commits since branch point
3-way merge needed (creates merge commit)
History stays perfectly linear with fast-forward. Use --no-ff flag to force a merge commit even when fast-forward is possible. Key vocabulary: fast-forward merge, branch pointer, linear ancestry, --no-ff flag.
5 / 10
A team needs to revert a feature that was merged with a squash. Why is reverting a squash merge easier than reverting individual commits?
Squash for reversibility — the rollback advantage:
Strategy
Revert process
Squash merge
git revert <single-SHA> — one command, done
15 individual commits merged
Identify all 15, revert in reverse order — or use git revert -m 1 <merge_SHA>
Squash = one commit = one natural atomic unit to revert. Key vocabulary: atomic revert, single-commit rollback, git revert vs. git reset, squash for reversibility.
6 / 10
Alice from the QA team just posted this Slack message: 'Hey @Bob, I'm seeing a conflict in the Jenkins build. It seems like merging directly into `main` is causing issues with some of our automated tests.' What's likely *causing* this conflict if Bob uses a rebase strategy?
Rebasing rewrites the commit history of Bob's branch by incorporating changes from `main`. This can create inconsistencies if Jenkins relies on a specific, unchanging commit graph. The build failures are a direct consequence of this altered history; it's not simply 'conflict resolution', but a fundamental divergence caused by the rebase.
7 / 10
David is writing the description for a Pull Request he's submitting. He wants to explain *why* he chose to rebase his feature branch onto `main`. Which of the following descriptions best explains this approach?
Rebasing demonstrates a commitment to staying synchronized with `main`. Explaining this explicitly communicates that David prioritized keeping his branch current and reducing merge complexity. Options A & D describe different workflows (fast-forwarding/squashing), while B is incorrect as fast-forwarding isn't the primary reason for rebasing.
8 / 10
Emily notices a merge commit in her Git repository with a 'merge bubble'. What does this visual element primarily indicate regarding the state of the branches?
The 'merge bubble' visually represents a divergent branch history. It signifies that the feature branch and `main` have branched off, undergone independent changes, and then merged back together. This usually indicates a more complex branching strategy where conflict resolution is expected during the merge process – it doesn't *mean* conflicts were resolved, just that they could be.
9 / 10
Frank runs `git rebase main` on his feature branch. After the rebase, he attempts to merge this updated branch back into `main`. What condition *must* be met for a fast-forward merge to occur?
A fast-forward merge only works when the feature branch hasn't diverged from `main`. This means that all commits on the feature branch are also present in the latest version of `main`. If there are conflicting changes, a standard (non-fast-forward) merge is necessary, which will result in a merge commit.
10 / 10
George wants to undo a feature that was merged with a squash merge. Which approach would be the *most* efficient and straightforward?
Squash merges combine all commits into a single commit. To undo this, you must revert that *single* squash commit. `git revert` creates a new commit that reverses the changes introduced by the specified commit. Options B and C are more complex and less direct; deleting the branch is not an effective solution to undoing a merge.
What does this Version Control Strategy Language exercise cover?
This exercise, "🔁 Merge vs. Rebase Vocabulary", tests your understanding of version control strategy language vocabulary and phrasing through 10 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Version Control Strategy Language exercise for?
It's designed for IT professionals and learners who want to sound natural discussing version control strategy language topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Version Control Strategy Language exercises?
Browse the full Version Control Strategy Language exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.