5 exercises — rebase vs merge, cherry-pick, bisect, detached HEAD, interactive rebase — Git concepts that come up in every PR review.
0 / 10 completed
1 / 10
"Should we rebase or merge this branch?" What is the key difference?
git merge integrates branches by creating a new merge commit that joins two histories — preserving full context. git rebase moves (replays) your commits onto the tip of another branch, rewriting history for a cleaner, linear log. Rule of thumb: rebase local feature branches before merging; avoid rebasing shared/public branches as it rewrites commit hashes.
2 / 10
Complete the sentence: "We used git _____ to apply only that one hotfix commit from the release branch onto main without merging the entire branch."
git cherry-pick <commit-hash> applies a specific commit from one branch onto another. Useful for backporting a bug fix to an older release branch, or grabbing a single feature commit without pulling everything else. It creates a new commit with a different hash but the same changes.
3 / 10
"The build is broken — let's use git bisect to find the bad commit." What does git bisect do?
git bisect performs a binary search: you tell it a known good commit and a known bad commit, then git checks out the midpoint. You mark each as good or bad until it identifies the exact commit that introduced the regression. Very efficient — O(log n) steps through hundreds of commits.
4 / 10
"My repository is in a detached HEAD state." This means:
Normally HEAD points to a branch name (e.g. ref: refs/heads/main). In a detached HEAD state, HEAD points directly to a commit hash. This happens when you git checkout <hash> or git checkout <tag>. New commits made here are reachable only by their hash — create a new branch with git branch <name> if you want to keep them.
5 / 10
"Before opening the PR, run an interactive rebase to clean up your commits." Interactive rebase (git rebase -i) lets you:
git rebase -i HEAD~N opens an editor listing the last N commits with commands: pick (keep), squash/fixup (combine with previous), reword (change message), drop (delete), edit (amend). Used to clean up "WIP" and "fix typo" commits into meaningful, atomic commits before merging a PR. Only do this on commits that haven't been pushed to shared branches.
6 / 10
Sarah from QA just flagged a potential conflict in the PR. She says: 'The merge is failing because of conflicting changes to the user_profile file. It seems like you've modified it while I was testing a new validation rule.' What does merge conflict most accurately describe in this situation?
A merge conflict arises when Git cannot automatically combine changes from two branches because they have overlapping modifications to the same lines or sections of a file. The QA team's message clearly indicates that different versions of user_profile were modified simultaneously, necessitating manual intervention to resolve the discrepancies. Option A is incorrect as it describes a successful merge; options C and D are unrelated concepts.
7 / 10
Ben in the Slack channel writes: 'I'm trying to revert my last commit but I'm getting an error. It says I need to use a detached HEAD state. What does this mean and how do I fix it?' Complete the sentence: 'A detached HEAD state means you are not on any branch, and you should git checkout ' to return to a proper branch.'
A detached HEAD state occurs when you've checked out a commit directly without checking out a branch – essentially, you're not associated with any named branch. This is often due to using commands like `git checkout `. Using `git checkout` will switch your HEAD back to a branch that already exists, providing a stable reference for future commits and preventing issues caused by working directly on the commit history. Options A, B, and D are all incorrect approaches.
8 / 10
David is describing a PR he's submitting for review. He says: 'I've used a commit message like this: `fix(user_authentication): Implement two-factor authentication`. What does the prefix in this commit message (e.g., `fix`, `feat`, `docs`) typically represent?
Commit message prefixes are a standard convention used to categorize and filter changes within Git repositories. They provide a high-level indication of the *type* of change – for example, `fix` indicates a bug fix, `feat` signifies a new feature, and `docs` denotes documentation updates. This allows developers to quickly understand the purpose of each commit without needing to examine the full commit message content. Option A is incorrect as prefixes don't specify file names.
9 / 10
Emily reports a build failure after merging a new feature branch into main. The error log indicates a conflict in the database_schema.py file. She asks you to use Git commands to resolve it. What is the primary advantage of using `git merge --abort` immediately after encountering such a conflict, before attempting any manual resolution?
`git merge --abort` provides a crucial safety net during conflict resolution by rolling back any partial merge operations. This allows you to discard potentially incorrect or incomplete changes made during the merging process and begin anew with a clean state. It's far safer than proceeding with a partially merged state, which could lead to further inconsistencies and difficult-to-debug issues. Option A is misleading; options C and D are not what this command does.
10 / 10
Frank explains: 'I'm using `git rebase -i HEAD~3` to interactively reorder my commits before submitting a PR. What is the core purpose of this command?
`git rebase -i HEAD~3` (or similar) enables interactive rebasing, giving you direct control over the commit history of your current branch. You can selectively edit, combine, or delete commits before merging them into another branch – essentially rewriting the branch's history to create a cleaner and more linear flow. Option D is incorrect as rebasing doesn't automatically resolve conflicts; it prepares you for manual resolution.
What does the "Git & Version Control Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to git & version control vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary 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 shows a real-world 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, and a full results screen at the end.
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.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
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 vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.