Git Interview Questions

A curated set of Git interview questions, ordered roughly from fundamentals to more practical, day-to-day scenarios — the kind you'll actually be asked in real screens and on-sites.

Branching and merging#

Q: What's the difference between rebase and merge? Merge combines two branches by creating a new merge commit with two parents, preserving exactly what happened including both lines of development. Rebase instead replays your branch's commits on top of another branch's latest commit, producing new commits (new hashes) and a clean, linear history with no merge commit — at the cost of rewriting history, which is only safe on commits that haven't been shared with anyone else yet.

Q: What is a fast-forward merge, and when does it happen? It happens when the branch you're merging into hasn't diverged at all since the feature branch was created — there's nothing to reconcile, so Git simply moves the target branch's pointer forward to the feature branch's tip, with no new commit created. If the target branch has moved forward in the meantime, Git instead creates a real merge commit to combine both histories.

Q: How do you resolve a merge conflict? Git marks each conflicting section in the affected file with <<<<<<<, =======, and >>>>>>> markers showing both versions of the conflicting lines. You manually edit the file to the version you want (deleting the markers entirely), stage the resolved file with git add, and then complete the merge with git commit.

History and undoing changes#

Q: What's the difference between git reset and git revert? git reset moves the current branch pointer backward (optionally also changing the staging area and working directory), effectively erasing commits from the branch's history — safe only on local, unpushed commits. git revert creates a brand-new commit that undoes the changes of a specified previous commit, leaving history intact — the safe option for undoing something that's already been pushed and shared, since it doesn't rewrite existing commits.

Q: What does git rebase -i let you do, and why would you use it? Interactive rebase lets you rewrite a range of your own recent, unpushed commits — reordering them, rewording commit messages, squashing several small commits into one, or dropping a commit entirely. It's most commonly used to clean up a messy sequence of work-in-progress commits into one or two clean, reviewable commits before opening a pull request.

Remotes and collaboration#

Q: What's the difference between git fetch and git pull? git fetch downloads new commits from the remote into local remote-tracking branches (like origin/main) without touching your currently checked-out branch. git pull does the same fetch but immediately merges (or rebases) those changes into your current branch, so your working branch is updated right away rather than requiring a separate merge step.

Q: A teammate says they can't push because Git rejected it — what's happening, and how do they fix it? The remote branch has commits they don't have locally yet, almost always because someone else pushed to that branch first. They need to fetch and integrate those new commits (via merge or rebase) into their local branch before pushing again — this rejection is a safety mechanism that prevents one push from silently discarding another person's work.

Hooks and team workflow#

Q: What's the difference between a pre-commit hook and a commit-msg hook? pre-commit runs before a commit message is even prompted for, and is typically used to lint or format the staged files, or block a commit outright (a leftover debug statement, unresolved conflict markers). commit-msg runs after the message has been written, and receives the path to a temp file containing it — its job is validating the message itself, such as enforcing that every commit follows a type(scope): summary convention.

Workflow strategy#

Q: What's the core trade-off between Git Flow and trunk-based development? Git Flow uses long-lived branches (develop, release/*, feature/*) with a clear, structured process, which suits products with genuinely scheduled, versioned releases — but feature branches that stay open for days or weeks drift further from develop every day, making eventual merges more conflict-prone. Trunk-based development has everyone integrate into one shared branch continuously, with branches (if used at all) living hours rather than weeks, which keeps merges small and frequent at the cost of demanding real CI discipline, since a broken main blocks everyone immediately.

Internals#

Q: What's the practical difference between git reset --soft, --mixed, and --hard? All three move the current branch's HEAD to the target commit; they differ in what else they touch. --soft leaves the index and working directory untouched, so the "undone" commit's changes show up as staged. --mixed (the default) additionally resets the index, so those changes show up as unstaged modifications instead. --hard goes further still and overwrites the working directory too, discarding any uncommitted changes entirely — the only one of the three that can lose work that wasn't committed.