Git Interview Questions
Interviewers ask about Git not to test trivia recall but to gauge whether a candidate understands version control deeply enough to work safely on a shared codebase — to know the difference between operations that rewrite history and ones that don't, to reason about what a command will actually do before running it, and to recover calmly when something goes wrong. The strongest answers explain the underlying model (commits, trees, refs) rather than reciting command syntax, because that understanding is what lets someone handle a novel situation they haven't seen a memorized answer for.
Cricket analogy: Like a selector who cares less whether a batter can recite the LBW law verbatim and more whether he understands the shot he's about to play and can adjust calmly mid-innings when the situation changes, not just execute a memorized textbook cover drive.
Conceptual questions that come up repeatedly
'What is the difference between git merge and git rebase?' is close to universal: merge creates a new commit with two parents, preserving both branches' actual history, while rebase replays commits onto a new base, producing a linear history but rewriting commit SHAs in the process. 'What is the difference between git fetch and git pull?' tests whether a candidate knows pull is fetch plus merge (or rebase, if configured), and that fetch alone is always safe because it only updates remote-tracking refs without touching the working directory. 'Explain git reset --soft, --mixed, and --hard' checks understanding of Git's three states — the tool moves the branch pointer in all three cases, but differs in whether it also resets the index (staging area) and the working directory.
Cricket analogy: Like the difference between combining two separate net sessions into one shared record that keeps both intact (merge) versus replaying one player's drills fresh on top of the other's latest session for a tidier log (rebase); and checking the scoreboard app for updates (fetch, always safe) versus checking and immediately updating your own scorecard to match (pull); reset's three modes are like moving your innings marker back while keeping runs on the board (soft), also erasing the tally (mixed), or wiping the whole scorecard clean (hard).
Scenario-based questions
Interviewers often pose situations rather than definitions: 'you committed to the wrong branch, how do you fix it', 'you need to undo a commit that's already been pushed and pulled by others, what do you do and why not use reset', or 'you accidentally deleted a branch with unmerged work, how do you get it back'. These test practical judgment: recognizing that 'git revert' is the safe choice for shared history because it adds a new commit rather than rewriting existing ones, and that 'git reflog' can locate a dangling commit's SHA after a branch deletion, letting you recreate the branch with 'git branch recovered-branch <sha>'. A candidate who reaches for 'git reset --hard' on a branch other people have already pulled, without acknowledging the disruption that causes downstream, is showing a gap that matters on a real team.
Cricket analogy: Like a bowler realizing mid-over he warmed up for the wrong match and needing to correct the record without erasing the over that's already been broadcast — you don't rewrite the scorecard (reset) once it's aired, you log a correcting entry (revert); and if a match file gets accidentally archived, the scorer's private notebook (reflog) still has the exact game ID to restore it.
# Classic 'I committed to main by mistake' recovery
git branch feature/oops # create a branch pointing at the current (wrong) commit
git reset --hard HEAD~1 # move main back one commit (safe: not yet pushed)
git checkout feature/oops # continue work on the correctly-named branch
# 'Undo a commit that others have already pulled'
git revert a1b2c3d # adds a new commit that undoes a1b2c3d's changes
# 'I deleted a branch and need it back'
git reflog # find the SHA the branch used to point to
git branch recovered-feature 9f8e7d6A strong signal in interview answers is explaining *why* one command is safer than another in context, not just naming the safer one. 'Use revert, not reset, because reset rewrites history that others have already based work on' demonstrates the underlying model; 'use revert' alone does not.
Be ready to explain the danger of 'git push --force' on a shared branch and the safer alternative 'git push --force-with-lease', which fails if the remote has commits you haven't fetched yet — interviewers frequently follow up a rebase question by asking exactly this.
Questions about collaboration and workflow
Beyond mechanics, interviewers assess workflow judgment: 'how do you resolve a merge conflict', 'what makes a good commit message', 'how would you structure commits in a large feature branch before opening a pull request'. These probe whether a candidate treats history as a communication tool for their team, not just a backup mechanism — for example, recognizing that squashing many small 'wip' commits into a few logically coherent ones before review makes the pull request easier to understand, while preserving fine-grained history might matter more in a codebase that leans on 'git bisect' for debugging regressions.
Cricket analogy: Like a captain judged not just on technical skill but on judgment — resolving a mid-match tactical disagreement with the vice-captain calmly, writing a clear post-match report instead of vague notes, and deciding whether to condense a chaotic warm-up into one clean summary for selectors or keep every drill logged separately for the analyst reviewing form dips ball by ball.
- Interview questions test the underlying mental model (commits, refs, history rewriting) more than command syntax memorization.
- Merge vs rebase: merge preserves original history with a two-parent commit; rebase rewrites SHAs to produce linear history.
- Fetch is always safe (updates remote-tracking refs only); pull is fetch plus merge or rebase, which can touch your working directory.
- Revert is the safe way to undo shared/pushed history; reset rewrites history and disrupts collaborators who already pulled it.
- git reflog is the standard recovery path for finding a SHA after a branch was deleted or a reset went wrong.
- Explaining *why* a command is safer in context is a stronger interview signal than simply naming the correct command.
Practice what you learned
1. What is the fundamental difference between git merge and git rebase?
2. Why is git fetch considered always safe to run?
3. Why should you use git revert instead of git reset to undo a commit that has already been pushed and pulled by teammates?
4. After accidentally deleting a branch that had unmerged commits, what is the standard first recovery step?
5. What advantage does 'git push --force-with-lease' have over a plain 'git push --force'?
Was this page helpful?
You May Also Like
Rebasing vs Merging
Compare git rebase and git merge as two different strategies for integrating branch changes, and learn when a linear history is worth the trade-offs of rewriting commits.
git revert vs git reset
Two different ways to undo changes in Git — revert creates a new commit that inverses a prior one, while reset moves the branch pointer and rewrites history — and when to use each safely.
Recovering Lost Commits with reflog
Discover how git's reflog silently tracks every movement of HEAD and branch tips, giving you a safety net to recover commits after resets, rebases, or accidental deletions.
Common Git Pitfalls
A field guide to the mistakes that trip up both new and experienced Git users, why each one happens, and how to avoid or recover from it.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics