Git interview fluency
The mental models a senior git interview really tests, each framed as what they probe plus the one-sentence answer: merge vs rebase, reset vs revert, what HEAD is, reflog recovery, force-with-lease, snapshot-not-diff storage. The whole track, distilled to recall-ready fluency.
Senior git interview questions are rarely about syntax — they probe whether you hold the right mental model. “Merge or rebase?” is not asking for a preference; it is checking whether you understand history as shared or local. The candidate who answers in one crisp sentence and names the tradeoff sounds senior; the one who lists commands sounds like they memorised a cheat sheet.
By the end of this lesson you will be able to answer the canonical git interview questions the way a senior does: name what each question is really testing, then give the one-sentence correct answer — turning the whole track into recall-ready fluency.
After this lesson you can field the core senior git questions — merge vs rebase, reset vs revert, what HEAD/a branch/the index are, recovering lost commits, fast-forward vs three-way, force-with-lease vs force, snapshot-not-diff storage, undoing a pushed commit — each as “what they’re testing” plus a one-sentence answer.
Merge vs rebase — they are testing whether you respect shared history. Both integrate one branch into another; the difference is what they do to history.
- Merge preserves history exactly and ties two lines together with a merge commit (two parents). Non-destructive, safe on shared branches, but history is non-linear.
- Rebase rewrites your commits onto a new base, producing a clean linear history — but it creates new commits, so it must never touch commits others have pulled.
One-sentence answer: “Rebase locally to keep my own branch clean and linear; merge to integrate into shared branches, because rebasing published history breaks everyone who has it.” That sentence — rebase local, merge shared — is the whole point.
Reset vs revert — they are testing rewrite-versus-append, and shared-versus-local. Both “undo,” but oppositely:
git revertappends a new commit that inverts an earlier one. History is preserved. Safe on shared branches — this is how you undo a pushed commit.git resetmoves the branch pointer backwards, rewriting history (and, with--hard, the working tree). Only safe on local, unpushed commits.
One-sentence answer: “Revert to undo something already pushed, because it adds a new commit and keeps history; reset to undo local commits, because it rewrites history and must not touch shared branches.”
What are HEAD, a branch, and the index? They are testing whether you know git’s actually-simple model. Three pointers and a staging area:
- A branch is just a movable pointer to one commit. Nothing more — a 40-char file under
.git/refs/. - HEAD is a pointer to the current branch (usually) — it says “where am I, and what will the next commit’s parent be.” Detached HEAD means it points straight at a commit, not a branch.
- The index (staging area) is the proposed next commit — the snapshot
git commitwill freeze.
One-sentence answer: “A branch is a pointer to a commit, HEAD is the pointer to my current branch, and the index is the staging area holding the snapshot my next commit will record.”
▸Why this works
Why does “a branch is just a pointer” matter so much in interviews? Because almost every confusing git behaviour dissolves once you hold it. Creating a branch is instant because it only writes one 40-byte file. Switching branches just moves HEAD. “Losing” commits after a reset is really just moving a pointer off them — the commits still exist, unreferenced, which is exactly why reflog can bring them back. The pointer model is the key that unlocks the rest.
Recovering lost commits and the storage model — they are testing whether you panic. Two linked questions:
- “You reset —hard and lost a commit — recover it?” “
git refloglists every position HEAD has held; I find the lost commit’s SHA there andgit branchorgit resetback to it — the commit was unreferenced, never deleted.” - “Does git store diffs or snapshots?” “Snapshots — each commit references a full tree of the project; git computes diffs on demand for display and stores objects efficiently (deltas in packfiles), but the model is a snapshot per commit, not a chain of patches.”
The snapshot model is why git is fast at branching and why checking out any commit is cheap: it just reads that commit’s tree.
Fast-forward vs three-way, and force-with-lease vs force — they are testing safety instincts. The two that separate seniors from the rest:
- Fast-forward vs three-way merge: “If the target branch hasn’t diverged, git just slides the pointer forward — a fast-forward, no merge commit. If both sides have new commits, git does a three-way merge using the common ancestor and creates a merge commit.”
- Why
--force-with-leaseover--force: “--forceoverwrites the remote unconditionally and can erase a teammate’s pushed commit;--force-with-leasefirst checks the remote is still where I last saw it and aborts if someone else pushed — so I never clobber work I haven’t seen.”
That last answer is the single most senior-sounding sentence in a git interview, because it shows you optimise for not destroying other people’s work.
A rapid-fire interview round, answered like a senior.
“Walk me through undoing a commit you already pushed to main.” — “Since it’s shared, I never rewrite history. I git revert <sha>, which appends a new commit inverting the change, and push normally. Reset would rewrite shared history and break every clone.”
“You did git reset --hard and your last two commits vanished — get them back.” — “They’re unreferenced, not deleted. git reflog shows every HEAD position; I find the SHA from before the reset and git reset --hard <sha> or git branch rescue <sha> to re-anchor them.”
“Rebase or merge for a feature branch about to land on main?” — “Rebase the feature onto origin/main while it’s still mine, to keep it linear and reviewable; the integration into main itself happens through the PR. I never rebase commits other people have already pulled.”
“Why --force-with-lease?” — “It refuses to push if the remote moved since my last fetch, so I can rewrite my own branch without ever clobbering a commit a teammate pushed to it.”
Four answers, four mental models — storage, pointers, integration, undo-safety — and no command memorisation in sight.
▸Common mistake
The trap is answering with commands instead of models. “How do I undo a pushed commit?” answered as “git reset —hard and force push” is a red flag — it shows you’d rewrite shared history. The senior answer leads with the principle (never rewrite what others have) and only then names the tool (revert). Interviewers are listening for the model under the command; lead with the model and the command follows naturally.
An interviewer asks: 'How do you undo a commit that's already on shared main, and why that way?' What's the senior answer?
A senior git interview tests mental models, not syntax, and they reduce to four: storage (git keeps snapshots, not diffs), pointers (a branch is a pointer to a commit, HEAD points to the current branch, the index is the next snapshot), integration (rebase local for linear history, merge shared; fast-forward when undiverged, three-way otherwise), and undo-safety (revert appends and is safe on shared history, reset rewrites and is local-only, reflog recovers unreferenced commits, force-with-lease never clobbers unseen work). Lead every answer with the principle, then name the command. That is the whole git track, distilled to recall-ready fluency — and the close of this capstone unit.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.