Git & GitHub Module 4
Branching and merging interview questions
Interview questions on branching and merging: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher
What is HEAD in Git?
-
Fresher
What is a fast-forward merge, and when does Git make one?
Answered in the lesson Merge branches: fast-forward and three-way
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Fresher to mid
You checked out a release tag to try a fix, made three commits there, then switched back to main. A teammate says the commits are gone. Are they? How do you get them back, and how would you avoid this next time?
- What it tests
- Detached HEAD, reachability, what Git keeps after you switch away (the reflog and garbage collection), and naming work with a branch.
- First step
- Say what happened first: on a detached HEAD the commits were reachable only from HEAD, so switching away left them without a name, not deleted. Git printed the newest one's ID as you left, and git reflog lists every commit HEAD has been on, so find the newest of the three and create a branch at it.
- Follow-ups
-
- How long will Git keep those commits if you do nothing?
- The commits were made two months ago. Does that change the answer?
- How do you keep this from happening to a teammate?
From the lesson Branches, HEAD and git switch
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Fresher to mid
Your team names branches feature/<ticket>. Creating feature/login fails with "cannot lock ref 'refs/heads/feature/login': 'refs/heads/feature' exists". Explain the cause, fix it without losing any work, and say how you would prevent it.
- What it tests
- How branches are stored as references, Git's naming rules, and renaming a branch safely, locally and on a shared repository.
- First step
- Read the message: a branch called feature already exists, and Git stores it as refs/heads/feature, a file, which cannot also be the folder that feature/login needs. Check what feature holds with git log feature, rename it with git branch -m to a name inside the scheme, such as feature/old-menu, then create the new branch.
- Follow-ups
-
- What changes if feature also exists on the shared remote?
- Two branches differ only in case, Fix and fix. What goes wrong on macOS?
- How would you enforce a naming rule for the whole team?
From the lesson Branches, HEAD and git switch
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Fresher to mid
git merge feature prints "Already up to date.", yet the change your teammate made on feature is not in your files. List the likely causes, and how you would check each one.
- What it tests
- What "Already up to date" really checks, ancestry and merge bases, local branches against their remote copies, and merges whose changes were later undone.
- First step
- Take the message literally: the tip of your local feature is already an ancestor of HEAD. Confirm it with git merge-base --is-ancestor feature HEAD and an echo. Then question the assumption that your feature holds the change: compare git log --oneline -1 feature with the commit your teammate pushed, and search the history of the file for a later commit or a revert that changed it back.
- Follow-ups
-
- The change is on the remote, not in your local feature. Why does git merge not see it?
- An earlier merge of feature was reverted. What happens on the next merge?
- How can the file differ even though every commit of feature is merged?
From the lesson Merge branches: fast-forward and three-way
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
In a merge commit, which parent comes first, and why does the order matter? Name two everyday commands whose result changes if you merge main into a feature branch and then fast-forward main to it, instead of merging the feature into main.
- What it tests
- Parent order in merge commits, first-parent history, git revert -m, and how the direction of a merge changes what tools that follow first parents report.
- First step
- The first parent is the commit HEAD was on when you ran git merge; the merged branches follow in order. Merging main into feature makes main's tip the second parent, and fast-forwarding main to that merge makes main's own line run through the feature's commits. Then walk git log --first-parent main and git revert -m 1 through both histories.
- Follow-ups
-
- What does git revert -m 1 undo, and what would -m 2 undo?
- Release notes come from git log --first-parent main. What goes wrong in the second history?
- How would you stop main from being fast-forwarded to such a merge?
From the lesson Merge branches: fast-forward and three-way
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
All Git & GitHub interview questions · The Git & GitHub track