Git Interview Questions: Explain Branching, Merging and History

Git interview questions rarely ask you to recite flags. They ask you to look at a repository, describe what is happening, and justify the next command. If you know the commands but freeze when someone asks why, the fix is not more memorisation. It is practice at narrating state and reasoning out loud.

This guide treats Git as a reasoning exercise. You will build a mental model you can draw while talking, learn how to name trade-offs instead of hunting for one right answer, and rehearse the recovery scenarios that separate people who have used Git from people who have only read about it.

Why Git Interview Questions Trip Up Otherwise Strong Candidates

Most candidates memorise commands. Few practise explaining the state of a repository out loud, which is the actual skill under test.

Interviewers use Git to check judgement. They want to know whether you understand what a command changes, what it leaves behind, and whether it is safe on history other people already have. A candidate who says "I would reset --hard" without mentioning what that discards is a risk to a shared branch, and interviewers hear that.

The shift is from "what does this command do" to "what would you do here, and why". Once you notice that shift, your preparation changes. You stop collecting trivia and start rehearsing decisions.

A practical way to prepare: pick three real repositories you have worked in. For each one, rehearse the story of a single messy moment. A merge that went sideways. A commit that landed on the wrong branch. A branch that drifted too far from main. You do not need dramatic stories. You need to be able to describe the state, the options, and the choice you made.

Start With the Model, Not the Commands

Almost every Git question maps back to one picture. Learn to draw it and you can answer most questions without reciting anything.

The three areas

Describe three places where changes can live:

• The working directory: files as they are on disk right now.
• The staging area, or index: the snapshot you are preparing for the next commit.
• The commit history: immutable snapshots already recorded.

Then every question becomes a movement problem. git add moves changes from the working directory toward the index. git commit turns the index into a new snapshot. git restore, and the older git checkout --, copies content from a commit back into the working directory or the index, while git checkout also switches branches. When someone asks what git reset does, you can answer by describing which of the three areas it moves and whether it touches history, rather than listing flags you half-remember.

Commits and branches

Explain commits as immutable snapshots, each pointing to a parent. A branch is a movable label pointing at one commit, not a folder of files. HEAD is where you currently are.

That single sentence answers a surprising number of follow-ups. Why does creating a branch feel instant? Because it writes a label. Why does rebasing change commit hashes? Because it creates new snapshots with new parents. Why does deleting a branch not delete work? Because the commits are still reachable until nothing points at them.

Practise it out loud

Draw the three areas and a few commits on paper while you talk. Then describe the same picture without the paper. This is the same technique as sketching a system design before answering: the drawing keeps you honest, and the spoken version proves you actually hold the model.

Branching and Merging: Naming the Trade-Off

Expect questions about long-lived versus short-lived branches. There is no single right answer, so state the trade-off and move on. Long-lived branches reduce merge conflicts for a team that releases on a schedule but drift further from main over time. Short-lived branches keep integration frequent but demand discipline about keeping main healthy.

Merge versus rebase

Describe what history looks like afterwards. A merge preserves both lines and adds a merge commit, so the graph shows when work came together. A rebase replays your commits on top of another branch, producing a straight line and new commit hashes.

Then name who is affected. If the branch is shared, rebasing rewrites commits your colleagues already have, and their next pull becomes confusing. Your git interview answers get stronger when you say that out loud rather than picking a side.

Fast-forward versus merge commit

A fast-forward simply moves the label forward when there is nothing to reconcile; the history stays linear. A merge commit records that two lines existed and were joined. Teams differ on which they prefer, and the useful answer explains what a reviewer will see in the log.

Conflict resolution as communication

Describe conflicts as a decision about whose change wins, and how you record that decision. A good answer includes reading both sides, understanding intent, talking to the other author when the intent is unclear, and leaving a commit message that explains the resolution. That is a collaboration answer wearing a Git costume.

History Questions: Rebase, Reset, Revert, Cherry-Pick

For each command, answer in three parts: what it changes, what it leaves behind, and whether it is safe on shared history. That structure alone will make your git technical interview answers sound considered.

Revert versus reset

git revert creates a new commit that undoes an earlier one. History is preserved, so anyone who already pulled is unaffected. git reset moves the current branch label backwards, and depending on the mode it may also change the index and the working directory. On a shared branch, revert is usually the safer public answer, and saying why shows you understand reachability rather than just syntax.

Interactive rebase for local tidying

Interactive rebase lets you reorder, squash and reword commits before review. The rule of thumb worth stating: tidy commits that only you have, and avoid rewriting commits that others have pulled. If you are unsure whether a branch is shared, check before you rewrite.

Cherry-pick as a targeted fix

Cherry-pick copies one commit onto your current branch. It is useful for pulling a single fix into a release branch without taking everything else. Mention the cost too: the same change now exists twice with different hashes, so a later merge can surface a conflict or a duplicate. Interviewers like hearing the downside without being prompted.

Recovery Scenarios: The Git Interview Questions That Reveal Experience

These prompts are common: "You committed to the wrong branch", "You pushed a secret", "You lost a commit after a hard reset".

Structure your answer in four steps:

1. Stop. Do not run more commands while you are guessing.
2. Assess what is still reachable. Ask what the branch label, the reflog and any other branches still point at.
3. Choose the least destructive fix that solves the problem.
4. Tell the team, especially if shared history or credentials are involved.

Reflog as the safety net

The reflog records where HEAD and branch labels have pointed recently. It is local to your clone, which is exactly why it can rescue a commit that no branch points at any more, and exactly why it cannot help a colleague who never had your commits. Explaining both halves of that sentence is a strong answer.

Be honest about experience

If you have not hit a scenario, say how you would investigate rather than inventing a war story. Interviewers can tell. "I have not lost a commit that way, but my first move would be the reflog, then I would check whether anyone else has the branch" is a better answer than a fabricated incident, and it is more useful to you as a candidate.

Team Workflow Questions: Reviews, Pull Requests and Conventions

Workflow questions check whether you make other people's lives easier.

Keeping commits reviewable

Small changes, clear messages, one logical change per commit. A reviewer should be able to read the log and understand the shape of the change before opening the diff. If a commit message needs the word "and" three times, the commit probably wanted to be three commits.

What a good commit message contains

A short summary line in the imperative, then a body explaining why the change was made if the reason is not obvious. Interviewers ask about this because it predicts how you will communicate in review threads.

Handling review feedback

Add new commits for feedback rather than force-pushing over a colleague's comments, unless your team has agreed that a clean history matters more. Rewriting the branch mid-review hides the conversation and forces reviewers to start again. If your team does squash on merge, say so, because that changes the trade-off.

Branch protection and conventions

Describe branch protection and required checks as guardrails: they stop accidental pushes to main and make tests a condition of merging. If you were introducing a convention to a team that has none, a reasonable approach is to write down the smallest useful rule set, apply it to new work, and let the team adjust it. Conventions that arrive as a document nobody read tend to be ignored.

Handling Git Interview Questions and Follow-Ups Calmly

Follow-ups usually probe depth, not trick you. "Why not just delete the branch?" is asking whether you understand reachability. "What if two people rebase the same branch?" is asking whether you think about other people's clones.

Use a short pause to pick the model you will reason from, then answer in one clear pass. If you do not know, say what you would check: the documentation, a scratch repository, or a teammate. That is a complete answer, not a failure.

Practising these follow-ups aloud is the same skill as any other interview answer: structure first, detail second. If you want a second set of prompts to rehearse alongside these, the Python Interview Questions: Concepts and Trade-Offs page covers a similar reasoning-first approach for language topics, and the Blog has more practice material.

A Practice Routine You Can Run This Week

You do not need a real team repository to build this skill. You need a scratch repository and a willingness to break things on purpose.

• Create a throwaway repository. Commit a few files, branch, merge, and then deliberately break it: force a bad merge, commit to the wrong branch, reset too hard. Fix each one while narrating out loud.
• Record yourself answering five Git questions from this article. Listen for filler words where a model would have been clearer.
• Pair with a friend who asks "why" after every answer you give. The first three whys are usually where the real understanding shows.
• Keep a one-page cheat sheet of the trade-offs you find hardest to explain, and review it before interviews.

The takeaway: interviewers are not testing whether you memorised Git. They are testing whether you can describe what a repository is doing, choose a safe next step, and explain the cost of the alternative. Rehearse that out loud and the commands take care of themselves. If you want a structured way to practise answering under a little pressure, start from Home.

Frequently asked questions

What Git questions are most common in technical interviews?

Most fall into four groups: explaining repository state (working directory, staging area, history), branching and merging trade-offs such as merge versus rebase, history commands like reset, revert and cherry-pick, and recovery scenarios such as committing to the wrong branch or losing a commit. Interviewers usually care more about your reasoning than the exact flags.

Should I say merge or rebase when asked about integrating changes?

Name the trade-off rather than picking a winner. Merge preserves both lines of history and adds a merge commit; rebase replays your commits and produces a linear history with new hashes. The deciding factor is usually whether the branch is shared, because rebasing rewrites commits other people may already have.

How do I answer a Git question if I have only used a GUI and not the command line?

Say so plainly, then describe what the GUI action does in terms of the underlying model: which area the change moves between, and whether it rewrites history. Candidates who can explain the model behind the buttons often answer better than candidates who only know command syntax.

What should I say if I do not know a Git command in an interview?

Say what you would check and how you would investigate. Naming the documentation, a scratch repository or a teammate is a complete answer. Guessing at a command that rewrites shared history is worse than admitting the gap and describing a safe way to find out.

How much Git detail is expected for a non-senior engineering role?

For most roles, you need the model rather than exhaustive flags: how commits, branches and the staging area relate, how to integrate changes, and how to recover from a mistake without damaging shared history. Deep internals rarely come up unless the role is specifically about developer tooling.

Can I prepare for Git questions without a real team repository?

Yes. A throwaway repository is enough. Deliberately create the mistakes you might be asked about, such as a bad merge or a commit on the wrong branch, then fix each one while narrating your reasoning. That rehearsal is what makes the answers sound calm in an interview.

Practise your Git answers out loud