Git is used by 93% of developers worldwide, yet Stack Overflow's annual survey reveals that "undoing changes" remains one of the most searched Git topics year after year. Why? Because most developers learn Git as a series of commands rather than understanding the underlying model of commits, references, and history.
These five questions test the mental model you have of Git, not just your ability to memorize commands. They consistently separate developers who've clicked buttons in VS Code from those who truly understand version control.
Question 1: The Reset vs Revert Confusion
This question appears in almost every Git interview, yet most candidates fumble it:
# You've made three commits on main that need to be undone
# The commits have already been pushed to origin
# What command do you use?
git log --oneline
# a1b2c3d Fix payment bug
# e4f5g6h Add logging
# i7j8k9l Update config
# m0n1o2p Previous good stateThe wrong answer: git reset --hard m0n1o2p followed by git push --force
The right answer: git revert a1b2c3d e4f5g6h i7j8k9l
Here's the mental model that makes this clear. Think of reset as a time machine that rewrites history—the commits literally disappear from the timeline. Think of revert as an "undo" operation that acknowledges the past—it creates new commits that reverse the changes.
When you reset on a shared branch and force-push, you're rewriting history that exists on other developers' machines. When they pull, Git gets confused because their local history no longer matches remote. This leads to duplicate commits, lost work, and angry teammates.
git revert is safe because it only adds to history. The bad commits still exist, but new commits undo their changes. Everyone's history stays consistent.
# Safe way to undo the last 3 commits
git revert HEAD~3..HEAD
# Or revert a specific commit
git revert a1b2c3d --no-edit
# Revert a merge commit (specify which parent to keep)
git revert -m 1 <merge-commit-hash>What interviewers are looking for: Understanding that reset rewrites history while revert preserves it. The best candidates explain the implications for team collaboration and mention that reset is only safe for local, unpushed commits.
Common follow-up: "When would you actually use reset?" Great candidates explain that reset --soft is useful for uncommitting work you want to restructure, reset --mixed (the default) unstages changes, and reset --hard is the nuclear option for completely discarding local experiments.
Question 2: The Reflog Recovery
This question tests whether you know Git's safety net exists:
# You accidentally deleted a branch with important work
git branch -D feature-important
# Or you ran a hard reset and lost commits
git reset --hard HEAD~5
# How do you get your work back?Most developers don't know that Git almost never truly deletes anything. The reflog is your lifeline—it records every time HEAD moves, including checkouts, commits, rebases, resets, and branch deletions.
# See the reflog
git reflog
# Output shows something like:
# a1b2c3d HEAD@{0}: reset: moving to HEAD~5
# x9y8z7w HEAD@{1}: commit: Add user authentication
# p5q6r7s HEAD@{2}: commit: Fix login bug
# m0n1o2p HEAD@{3}: checkout: moving from main to feature-importantEach entry has a reference like HEAD@{n} that you can use to travel back in time:
# Recover to the state before the reset
git reset --hard HEAD@{1}
# Or create a new branch pointing to the lost commit
git checkout -b recovered-branch x9y8z7w
# Or cherry-pick specific lost commits
git cherry-pick x9y8z7w p5q6r7sThe reflog is local to your machine and entries expire after about 90 days by default. This is why it can save you from local disasters but not from commits that were never on your machine.
What interviewers are looking for: Knowledge that reflog exists and how to use it. Bonus points for mentioning that ORIG_HEAD is another safety mechanism—Git sets it before dangerous operations like rebase or reset, so git reset --hard ORIG_HEAD often recovers from the most recent disaster.
Question 3: The Detached HEAD Mystery
This question reveals whether you understand what HEAD actually is:
git checkout a1b2c3d
# You are in 'detached HEAD' state...
# You make some commits
git commit -m "Experimental feature"
git commit -m "More experiments"
# Then you checkout main
git checkout main
# What happened to those commits?The answer: Those commits are orphaned. They still exist in the repository, but no branch points to them. Eventually, Git's garbage collection will delete them (unless you find them via reflog first).
Understanding this requires knowing what HEAD is. HEAD is normally a symbolic reference—it points to a branch name like refs/heads/main, and that branch points to a commit. When HEAD is "detached," it points directly to a commit hash instead of a branch.
Think of branches as named bookmarks in a book. HEAD is the page you're currently reading. Normally HEAD says "I'm reading the page that the 'main' bookmark points to." In detached HEAD state, HEAD says "I'm reading page 47" with no bookmark involved.
When you commit in detached HEAD, you add new pages after page 47. But when you jump to a bookmarked page (checkout a branch), those new pages have no bookmark pointing to them—they're lost in the book.
# The fix: create a branch before switching away
git checkout a1b2c3d
git commit -m "Experimental feature"
git checkout -b save-my-experiments # Now it's safe!
git checkout mainWhat interviewers are looking for: Understanding that branches are just pointers to commits, and that HEAD can either point to a branch (normal) or directly to a commit (detached). The best candidates explain why detached HEAD is useful—for temporarily exploring old commits or testing something without affecting any branch.
Question 4: The Cherry-Pick Strategy
This question tests practical Git workflow knowledge:
# You're on the release-2.0 branch
# A critical bugfix was committed to main
# You need ONLY that bugfix, not other main commits
git log main --oneline
# f1e2d3c Refactor user service (DON'T WANT)
# a4b5c6d Fix critical payment bug (WANT THIS)
# g7h8i9j Add new feature (DON'T WANT)Cherry-pick lets you apply specific commits to your current branch:
git checkout release-2.0
git cherry-pick a4b5c6dBut here's where it gets interesting. Cherry-pick creates a new commit with a different hash. The changes are identical, but Git sees them as separate commits. This matters for merge conflict resolution later—Git might not recognize that the same fix exists on both branches.
The -x flag helps with traceability:
git cherry-pick -x a4b5c6d
# Commit message automatically includes:
# (cherry picked from commit a4b5c6d)When to use cherry-pick:
- Applying hotfixes to multiple release branches
- Recovering specific commits from an abandoned branch
- Pulling in a single feature without merging an entire branch
When NOT to use cherry-pick:
- As a regular workflow (it duplicates commits)
- When you need many commits (consider merging instead)
- When commits have dependencies on each other
# Cherry-pick a range of commits
git cherry-pick A^..B # Includes A through B
# Cherry-pick without committing (stage changes only)
git cherry-pick -n a4b5c6d
# Handle conflicts during cherry-pick
git cherry-pick a4b5c6d
# ... resolve conflicts ...
git add .
git cherry-pick --continueWhat interviewers are looking for: Understanding that cherry-pick duplicates commits (doesn't move them), and awareness of the traceability implications. Strong candidates mention the -x flag and explain scenarios where cherry-pick is the right tool versus when merging is better.
Question 5: The Bisect Investigation
This question separates Git users from Git power users:
# Users report that login is broken
# It worked in version 2.0 (commit abc123)
# It's broken in current main (commit xyz789)
# There are 200 commits between them
# How do you find which commit broke it?You could check out each commit manually—but that's 200 tests. Git bisect uses binary search to find the culprit in about 8 steps (log2 of 200):
# Start bisect
git bisect start
# Mark current commit as bad
git bisect bad
# Mark known good commit
git bisect good abc123
# Git checks out a commit in the middle
# Bisecting: 100 revisions left to test
# Test the login functionality, then:
git bisect good # if login works
# or
git bisect bad # if login is broken
# Git narrows down further
# Bisecting: 50 revisions left to test
# Repeat until:
# a4b5c6d is the first bad commitFor extra power, automate the testing:
# If you have a test script that returns 0 for good, non-zero for bad
git bisect start HEAD abc123
git bisect run npm test -- --grep "login"
# Git runs the test automatically at each step
# Returns the exact commit that introduced the failureWhen you're done:
git bisect reset # Returns to original HEADThe logarithmic efficiency is why bisect is invaluable for large repositories. Finding a bug among 1000 commits takes only about 10 steps.
What interviewers are looking for: Knowledge that bisect exists and understanding of its binary search nature. Excellent candidates mention the automated bisect run option and explain that bisect only works well when commits are reasonably atomic—if one commit contains 50 unrelated changes, bisect finds the commit but you still have to hunt for the problematic line.
Key Concepts That Connect These Questions
After walking through these five questions, you'll notice they all test the same underlying understanding:
Git is a content-addressed filesystem. Commits, trees, and blobs are identified by SHA-1 hashes of their content. Understanding this explains why cherry-pick creates new hashes (the parent is different) and why reset can "delete" commits (it just moves the branch pointer—the commits still exist until garbage collected).
References are just pointers. Branches are files containing commit hashes. HEAD is a file containing either a branch name or a commit hash. This explains detached HEAD, why branching is cheap, and why reflog can save you.
History can be preserved or rewritten. Revert preserves history by adding new commits. Reset, rebase, and amend rewrite history by changing what commits exist. This distinction is crucial for collaboration.
Git almost never deletes anything immediately. Reflog, ORIG_HEAD, and the object database give you multiple safety nets. Understanding this transforms scary commands into recoverable experiments.
Practice Challenge
Here's a scenario to test your understanding:
# You're on feature-branch with 5 commits
# You rebase onto main and there are conflicts
# After resolving conflicts, you realize you made mistakes
# You want to start the rebase over from scratch
# How do you do it?The answer uses what we've learned: git reflog shows entries like rebase started, and git reset --hard ORIG_HEAD (or the specific reflog entry) restores your branch to pre-rebase state. Then you can start the rebase again with a clean slate.
If you worked through that confidently, you're ready for Git interviews.
Wrapping Up
These five questions represent the Git knowledge that interviewers use to distinguish developers who truly understand version control from those who've just memorized commands. They're not trick questions—they're diagnostic tools that reveal your mental model of how Git works.
The common thread? Each question tests whether you can reason about Git as a system of pointers and objects, not just a collection of commands. Interviewers want to see that you understand why Git behaves the way it does, which means you can troubleshoot novel problems instead of searching Stack Overflow for every issue.
Want to practice more? Our collection includes 800+ interview questions covering Git, JavaScript, React, Angular, TypeScript, and more—each with detailed explanations like these.
Related Articles
If you found this helpful, check out these related guides:
- Complete DevOps Engineer Interview Guide - comprehensive preparation guide for DevOps interviews
- Git Rebase vs Merge Interview Guide - When to rebase vs merge and why
- Node.js Advanced Interview Guide - Event loop, streams, and Node.js internals
- CI/CD & GitHub Actions Interview Guide - Workflows, pipelines, and deployment strategies