Top 50 Git Interview Questions 2026

Git is the assumed-knowledge layer for most engineering interviews. Nobody designs a whole loop around it, but a five-minute Git tangent can sink an offer if you fumble it. The questions below are the ones that come up over and over - sometimes during a coding round, sometimes during a behavioral round when the interviewer asks "describe a tricky merge you handled."

This post is structured the way an interviewer probes: from "do you actually know what a commit is" up through "can you recover a branch a teammate accidentally force-pushed."

Part 1: Fundamentals (1-12)

1. What is a Git commit, really?

A commit is a snapshot of the repository plus metadata: tree pointer (the file tree), parent commit(s), author, committer, message, and a hash that uniquely identifies the commit by its contents. Git commits are immutable. "Editing a commit" actually means creating a new one and moving a reference.

2. What is the difference between git pull and git fetch?

git fetch downloads remote refs and objects but does not modify your working tree or current branch. git pull is git fetch followed by either git merge or git rebase (depending on config) on the upstream branch. Pull is convenient. Fetch is what you want when you need to think before integrating.

3. What is HEAD?

A symbolic reference to the current commit. Usually it points to a branch, which points to a commit. When HEAD points directly at a commit (e.g., after git checkout <hash>), you are in "detached HEAD" state.

4. What is the index (or staging area)?

A binary file at .git/index that describes the next commit. git add writes a tree of file contents into the index. git commit snapshots the index and links it to the parent.

5. Walk me through the three states of a file in Git.

Modified (changed in working tree), staged (added to the index), committed (stored in the object database). The most common confusion: a staged file that is then re-edited is both staged (old version) and modified (new version) until you git add again.

6. What is the difference between a branch and a tag?

Both are references to commits. Branches move when you commit. Tags do not - they are intended as fixed pointers to a release or milestone. Annotated tags (git tag -a) carry their own metadata; lightweight tags are just refs.

7. What is a remote-tracking branch?

A local read-only ref like origin/main that mirrors the state of a branch on a remote. Updated by git fetch. You cannot commit directly to a remote-tracking branch.

8. What is git stash and when should I use it?

A side-stack of uncommitted changes. Use it when you need to interrupt your work to do something else (pull a fix, switch branches), without committing half-done code. Modern alternative: just commit a WIP commit on a feature branch and rebase later.

9. What is the reflog?

A log of every place HEAD has pointed in the last 90 days (default). Your "I just deleted my work" lifeline. git reflog shows it; git reset --hard HEAD@{2} jumps back two HEAD positions.

10. What is a fast-forward merge?

A merge where the target branch is a direct ancestor of the source. Git just moves the pointer forward instead of creating a merge commit. You can disable it with git merge --no-ff to always create a merge commit (some teams prefer this for traceable history).

11. What is a three-way merge?

When two branches have diverged, Git uses the common ancestor plus the two tip commits to compute the merged result. Conflicts happen when both sides modified the same lines in incompatible ways.

12. What does .gitignore actually do?

Tells Git which untracked files to ignore. Already-tracked files are not affected - .gitignore does not retroactively untrack them. Use git rm --cached <file> to stop tracking something and add it to .gitignore.

Part 2: Branching and Rebasing (13-22)

13. Rebase vs merge - which should I use?

Both are correct in different contexts. Rebase rewrites history to produce a linear sequence of commits, easier to read. Merge preserves the actual history of when branches integrated. Most teams in 2026: rebase feature branches onto main before opening PRs, then merge (or squash-merge) the PR.

14. What is git rebase -i good for?

Interactive rebase. Lets you reword, squash, fixup, drop, or reorder commits before merging. The standard pre-PR cleanup tool. Caution: never interactive-rebase commits that are already on a shared branch.

15. What is the "golden rule" of rebasing?

Do not rebase commits that exist outside your local repository. Once a commit is pushed to a shared branch, rewriting it forces collaborators to do recovery work and breaks any branch that was based on the old commit.

16. How do you squash the last 3 commits into one?

git rebase -i HEAD~3
# mark the second and third lines as 'squash' (or 's')

Then edit the combined commit message.

17. How do you cherry-pick a commit from another branch?

git cherry-pick <hash>

This applies the diff of that commit on top of your current branch as a new commit. Useful for backporting fixes. If conflicts arise, resolve them and git cherry-pick --continue.

18. What is git rebase --onto?

Rebase onto a different base than the current upstream. Common use: "I branched off the wrong branch, move my commits to this other branch." Example:

git rebase --onto main feature-old feature-new

Moves commits in feature-new that were after feature-old onto main.

19. How do you abort a rebase?

git rebase --abort

Returns the repo to the state before the rebase started. Always your bailout when conflicts are getting messy.

20. What happens if you git push --force to main?

You overwrite the remote's history. Anyone who based work on the previous tip now has an orphaned branch. Most modern repos block this with branch protection. Acceptable on a personal feature branch you are the only one using; never on shared branches. Prefer --force-with-lease.

21. What does git push --force-with-lease do differently?

It only overwrites the remote if your local view of the remote ref matches the actual remote ref. So if a teammate pushed to your feature branch in the meantime, the force-push is rejected. Always use this instead of plain --force when you must rewrite history.

22. Walk me through a typical Git Flow workflow.

Long-lived develop branch. Feature branches branch off develop and merge back. Release branches branch off develop for release stabilization, then merge to main (tagged) and back to develop. Hotfixes branch off main. Most teams in 2026 have moved to trunk-based development with short-lived branches off main. Be ready to talk about both and explain why your team picked what they picked.

Part 3: Conflicts and Recovery (23-32)

23. How do you resolve a merge conflict?

git status shows conflicted files. Open each, look for <<<<<<<, =======, >>>>>>> markers, resolve manually or with a merge tool (git mergetool). Then git add the resolved files and git commit. For rebases, git rebase --continue.

24. What is a merge driver and when do you need a custom one?

A program Git uses to merge two versions of a file. Custom drivers are useful for files where line-based merge does not make sense (lockfiles, generated code, binary blobs). Configure in .gitattributes and .git/config.

25. I accidentally committed to the wrong branch. How do I move the commit?

git log -1                            # find the hash
git reset --hard HEAD~1               # remove from current branch
git checkout correct-branch
git cherry-pick <hash>                # apply on the correct branch

Or use git reflog to find the commit if you have already lost the hash.

26. I committed a secret. How do I fully remove it?

If not yet pushed: git reset --soft HEAD~1, edit the file, commit again. If pushed: rotate the secret immediately first - assume it is compromised. Then rewrite history with git filter-repo (or BFG Repo-Cleaner), and force-push. Communicate with the team because everyone will need to rebase.

27. How do you find which commit introduced a bug?

git bisect. Mark a known-good commit and a known-bad commit; Git binary-searches between them. At each step you mark the checked-out commit good or bad. Pairs well with a test script via git bisect run.

28. What is git reset --soft, --mixed, and --hard?

• --soft moves HEAD only; index and working tree untouched.
• --mixed (default) moves HEAD and resets the index; working tree untouched.
• --hard moves HEAD, resets the index, and resets the working tree. Destructive.

29. I git reset --hard and lost two days of work. Can I get it back?

Probably yes, via git reflog. As long as the commits existed on HEAD at some point, the reflog has them for ~90 days. Find the hash and git reset --hard <hash> or check out a recovery branch. The orphaned objects are garbage-collected eventually, so do this soon.

30. What does git fsck --lost-found do?

Finds dangling commits and trees that are unreachable from any ref. Useful when even the reflog cannot help you (rare, but it has saved careers).

31. A teammate force-pushed and clobbered my branch. Recover it.

If you have a recent local copy: git reflog to find the pre-force-push tip, force-push that back. If only the teammate's machine has it: ask them for their reflog. If neither has it: check the CI runner, the GitHub events API, or any clone (Heroku, Vercel, a fork). The hash is the only thing you actually need to recover the branch.

32. What is a detached HEAD and when is it dangerous?

When HEAD points to a commit, not a branch. Commits made in detached HEAD have no branch holding them; if you check out something else, those commits become reachable only via the reflog and are eventually garbage-collected. Always create a branch before committing in detached HEAD: git switch -c new-branch.

Part 4: Internals and Advanced (33-42)

33. What is a Git object?

The fundamental unit. Four types: blob (file contents), tree (directory listing of blobs and other trees), commit (snapshot pointing to a tree), tag (annotated tag). Stored in .git/objects keyed by SHA-1 hash of the contents (SHA-256 is supported in newer Git versions but not yet default).

34. Why is Git's storage so efficient even with full history?

Git stores blobs once. If you have the same file in 100 commits unchanged, it is one blob with 100 commits referencing it through their trees. Periodically, git gc runs and packs loose objects into pack files, applying delta compression for similar files.

35. What is a packfile?

A compressed file in .git/objects/pack/ containing many objects with delta compression. Created by git gc or git repack. Reduces a large .git directory dramatically.

36. How does Git ensure integrity?

Every object is content-addressable: the hash IS the address. Tampering with any object changes its hash, which breaks every commit referencing it. This is also why Git is migrating from SHA-1 to SHA-256.

37. What is .git/config and how does it differ from ~/.gitconfig?

.git/config is repo-local configuration. ~/.gitconfig is user-global. There is also /etc/gitconfig system-wide. Precedence: local > global > system. Inspect with git config --list --show-origin.

38. What is a Git hook?

A script in .git/hooks/ that Git runs at certain points: pre-commit, commit-msg, pre-push, post-merge, etc. Used for linting, testing, message validation. Hooks are local to a clone (not committed to the repo) - which is why projects use tools like Husky or pre-commit to install them automatically.

39. What is git worktree?

Lets you check out multiple branches into separate working directories that share one .git directory. Useful when you need to test branch A while still working on branch B without context-switching. Replaces the old "have two clones" pattern.

40. What is sparse checkout?

A way to clone or check out only part of a repository. Necessary in monorepos where pulling all 5 GB just to work on one service is wasteful. Combined with partial clone, you get manageable monorepo workflows.

41. What is partial clone (--filter=blob:none)?

A clone that omits blob contents until needed. The repo has commit/tree metadata but downloads file contents on demand. Major speedup for large repos.

42. What is git rerere?

"Reuse Recorded Resolution." When you resolve a conflict, Git remembers it. If the same conflict arises again (during a long-running rebase, for example), Git can reapply your resolution automatically. Enable with git config --global rerere.enabled true.

Part 5: Workflows and Practical Use (43-50)

43. What is a monorepo and how do you scale Git for one?

A repo containing many projects. Scaling techniques: partial clone, sparse checkout, virtual file systems (VFS for Git), commit graph optimization, file system monitor, and judicious use of submodules or vendor directories. Companies running monorepos at scale often layer custom tooling on top (Bazel, Buck, Nx).

44. What are submodules and when should I avoid them?

A pointer in your repo to a specific commit in another repo. Useful for vendored dependencies you must edit locally. Avoid them when subtree merges or proper package management would work, because they introduce real workflow friction (especially for new contributors).

45. What is a subtree?

An alternative to submodules where one repo's history is merged into a subdirectory of another. Less friction for users (no extra commands), but harder to push changes back upstream.

46. How do you sign commits and why would you?

git commit -S -m "message"

Signs the commit with your GPG (or SSH) key. Useful for proving authorship in environments where impersonation is a real concern (open source, security-sensitive teams). GitHub shows verified commits with a green badge.

47. What is git blame and when does it lie?

Shows who last modified each line. Lies when commits were rebased, file was renamed, or auto-formatters touched everything. Counter-tools: git blame --ignore-revs-file to skip formatting commits. git log -p -- <file> is often more useful than blame.

48. What is the difference between git log and git reflog?

git log shows the commit graph reachable from a ref (default: HEAD). git reflog shows your local history of where HEAD (or other refs) have pointed - including commits no longer reachable from any branch. Reflog is local-only and not pushed.

49. Walk me through your typical PR workflow.

Be specific. A good answer for 2026: "Branch off main, make small commits as I work, rebase onto main before opening the PR, squash-merge unless the commits tell a story worth keeping. Pre-push hooks run lints and unit tests. CI runs the full suite. Use draft PRs to share early. After merge, delete the branch and pull main."

50. What is your most painful Git story?

This is a real interview question and a great one. Have an answer ready. The structure: what happened, what you tried first, what actually worked, what you learned. Bonus points if the lesson maps to "now I always use --force-with-lease" or "now I always rebase locally before pushing."

How to Drill These Effectively

The questions test two things: do you know the model, and have you used Git in anger?

For the model: read the first three chapters of Pro Git. Free, excellent, and answers 80% of these questions in passing.

For the practice: clone a real repo, deliberately make a mess (force-push, conflict, lost commit), and recover it. Doing this twice is worth ten hours of memorizing answers.

If you want to drill these under interview conditions with an interviewer who probes follow-ups, gitGood has a Git question bank covering this material, and the chat-based AI mock interview lets you practice explaining Git workflows while an AI interviewer presses for depth.

#git #interviews #devops #version-control #career