Git & version-control interviews
Git interview questions: how to answer them out loud.
Git interview questions test one thing before an employer lets you near a shared repository: whether you can explain your workflow clearly, out loud, without hand-waving. They come up in technical screens, in co-op and internship interviews, and in any role that touches a team codebase. Below are the questions that actually recur — merge versus rebase, resolving a conflict, what you do when you break main, branching, a clean pull request, fetch versus pull, and how to undo safely — with correct answers, plus how to rehearse saying them out loud against an AI interviewer that scores every reply.
What they're really testing
A git question is a trust check, not a trivia quiz.
The premise is practical. Before a team hands you commit access to a repository other people depend on, they want to know you won't rewrite shared history, force-push over a teammate's work, or freeze the first time a merge conflict appears. So they ask you to explain how git works in your own words. These questions usually sit inside a broader technical interview, and they carry real weight: the structured interview built around questions like these is the strongest predictor of job performance employers have, at an operational validity of .42 (Sackett, Zhang, Berry & Lievens, 2022).
The tell is that most git questions are "explain" or "what would you do," not "type the command." The interviewer is listening for judgment: do you know when to merge and when to rebase, why you'd revert instead of reset on a shared branch. A candidate who can recite flags but can't say why one is safe reads as someone who copied commands without understanding them. This matters most for co-op and internship candidates who haven't worked in a shared repo yet and have to show the understanding out loud rather than point to years of it.
How to answer
A good git answer has four beats.
You don't need to memorize man pages. Almost every version-control question yields to the same shape, and once you know it you can answer a question you've never heard the same way you'd answer a familiar one.
-
Name it plainly
One sentence on what the command or concept actually does. "Rebase replays my commits on top of the target branch." Start concrete.
-
Contrast it
Most git questions are "X versus Y." Say how it differs from its neighbor. The contrast is where real understanding shows.
-
Say when you'd reach for it
The judgment call. This is what they're actually probing: do you know when, not just what. Tie it to a real situation.
-
Flag the caveat
The gotcha that signals experience: don't rebase shared history, don't force-push main, don't hard-reset work you'd miss.
The shape keeps you from either dumping every flag you know or trailing off with "I'd just look it up." It's the same discipline that carries a clear walkthrough of a project you built: name it, contrast it, justify it, flag the risk.
Common questions
The git questions you should expect.
Most version-control interviews circle the same handful of topics. If you can answer these four cleanly out loud, you can adapt to almost any follow-up an interviewer chains on.
"What's the difference between merge and rebase?"
They're testing whether you understand history, not just commands. Name the trade-off: merge preserves it, rebase rewrites it.
"You just pushed a commit that broke the build. What now?"
They want to hear "revert, don't force-push shared history, tell the team." The wrong instinct here is a real red flag.
"Walk me through taking a feature from branch to merged."
Show the loop: branch off main, small commits, open a pull request, review, merge. Never straight to a protected branch.
"What's the difference between git pull and git fetch?"
They're checking you know pull integrates and fetch doesn't. Say fetch is safe to inspect; pull fetches and then updates your branch.
Problem → Solution
Reading git docs builds recognition. Explaining your workflow out loud builds the skill.
You can read the whole git handbook and still stumble when someone asks you to explain rebase out loud, because the skill being tested is live articulation, not recognition. Saying it yourself under pressure, fielding the follow-up ("okay, so when would you not rebase?"), and being shown where your explanation got fuzzy is a different act from reading. Practicing the skill beats reviewing it: at a one-week delay, a tested group recalled 56% of material versus 42% for a group that only re-read it (Roediger & Karpicke, 2006), and specific, immediate feedback is what turns a rep into an improvement (Wisniewski, Zierer & Hattie, 2020).
Explain your git workflow out loud and get scored on whether it actually held together. In Rehearsal Room you answer real git and version-control questions out loud against an AI counterpart that pushes back with the follow-ups a senior engineer would ask, and the forensic debrief afterward grades your answer: whether you named the concept, drew the right contrast, justified when you'd use it, and caught the caveat, or whether you said something subtly wrong, like reaching for reset on a shared branch. It flags the exact line that slipped and the phrasing worth keeping. Rehearsal, not cheating, because you build the explanation before the interview, not during it.
Pick a question you didn't pre-script — "merge or rebase?" — answer it out loud, and read the score on each beat. Carry the weakest beat into the next rep and drill it. Repeated retrieval is what makes it stick, and stopping after one clean answer gives most of the gain back (Karpicke & Roediger, 2008), so run a handful of questions across a week until you can explain your workflow without reaching for the words.
Questions & answers
Git interview questions, answered correctly.
What's the difference between git merge and git rebase?
Both integrate changes from one branch into another; the difference is what they do to history. Merge creates a new merge commit that ties the two branches together and keeps the true, branching history, so you can see exactly when the branch split off and when it joined. Rebase replays your commits one at a time on top of the tip of the target branch, producing new commits with new hashes and a single straight line of history, as if you'd started your work from the latest code. Merge is safe on shared branches because it doesn't alter existing commits; rebase rewrites them, so the rule is: don't rebase commits you've already pushed and others may have pulled. A strong answer names that trade-off out loud — merge preserves history and is safe to share, rebase gives a clean linear history but belongs on local, unpushed work.
How do you resolve a merge conflict?
A conflict happens when two branches change the same lines of the same file (or one edits a file the other deleted) and git can't safely pick a side. Git pauses and marks the file: your current branch's version sits above the ======= divider after <<<<<<< HEAD, and the incoming version sits below it, up to >>>>>>>. You read both sides to understand what each was trying to do, edit the file down to the correct combined result, and delete the markers. Then you git add the file to mark it resolved and finish with git commit (or git rebase --continue if the conflict came up during a rebase); git merge --abort bails out to where you started. The answer they want isn't the commands — it's that you read both sides and understand the intent before you pick, and check with the other author when it's genuinely ambiguous.
What do you do if you push a bad commit or break main?
On a shared branch, the safe move is git revert <commit>, which creates a new commit that applies the inverse of the bad one. It undoes the change while leaving history intact, so nobody who already pulled gets their branch rewritten out from under them. What you avoid is force-pushing a reset over a shared branch to erase the commit, because that rewrites public history and breaks everyone downstream. If the bad commit is still local and unpushed, you have more freedom and can reset or amend it. The mature answer leads with "don't panic, don't force-push shared history, revert it and tell the team," which shows you understand that other people depend on that branch.
What's the difference between git fetch and git pull?
git fetch downloads new commits and branch refs from the remote and updates your remote-tracking branches (like origin/main), but it doesn't touch your working branch or your files, so you can inspect what came in before you integrate it. git pull is git fetch followed immediately by an integration step: by default it merges the upstream branch into your current branch, or rebases if you run git pull --rebase or configure it that way. So the honest one-line answer is: fetch gets the changes and lets you look before you leap, and pull gets them and updates your current branch in one step.
What's the difference between git revert and git reset?
They solve different problems. git revert adds a new commit that reverses an earlier one, so history is preserved — the safe way to undo something already pushed and shared. git reset moves your branch pointer back to an earlier commit, dropping the commits after it from the tip. It comes in three flavors: --soft keeps your changes staged, --mixed (the default) keeps them in your working directory but unstaged, and --hard throws the changes away entirely. Because reset rewrites the branch's history, it's meant for local, unpushed work; reverting is what you reach for on anything others already have. Knowing which is safe on a shared branch is the whole point of the question.
What does a clean pull request look like?
Small and focused — it does one thing, so a reviewer can actually hold it in their head. It has a clear title and a description that says what changed and why, links the ticket, and passes CI before you ask anyone to look. A clean pull request is one you've read yourself first: no stray debug code, no unrelated changes bundled in, commits that tell a coherent story. Interviewers ask because a good pull request is really about respect for the reviewer's time, and that signals how you'll work day to day on a team.
How should you talk about your branching workflow?
The common shape is short-lived feature branches: you branch off main for one ticket, keep the branch small and focused, and open a pull request to merge it back after review, rather than committing straight to main. Teams formalize this in a few ways — trunk-based development keeps branches very short and merges to main often, while Git Flow adds longer-lived develop, release, and hotfix branches. You don't need to recite a named model; the point is to show you branch per unit of work, keep branches short so merges stay small, and never push straight to a protected main. If you've used a specific flow, name it and say why it fit the team.
What's the best way to practice git interview questions?
Out loud, against questions you didn't pre-script, with feedback on whether the explanation actually held. Reading the docs builds recognition, not the ability to explain rebase under pressure. Saying your own answer, fielding the follow-up, and being shown where you got fuzzy or slightly wrong is what transfers to the real screen.
Is there a tool to practice git interview questions?
Yes. Rehearsal Room lets you answer git and version-control questions out loud against an AI interviewer and scores you on whether your explanation held — concept, contrast, judgment, and caveat — flagging the exact line that slipped in a forensic debrief. It runs in your browser and is built to drill the skill of explaining your workflow, not to feed you answers.
Explain your git workflow out loud. Get scored on every beat.
Answer real version-control questions against an AI interviewer and get a forensic debrief on whether your explanation actually held — concept, contrast, judgment, and caveat. Rehearsal, not cheating.
Start practicing →More from Rehearsal Room: technical interview practice · explain your project · co-op & internship interviews · all interview guides.