Git interview questions: 25 questions with answers

Git comes up in almost every interview for developers, QA engineers and DevOps engineers: sometimes as a dedicated section, sometimes in passing ("how would you roll back a bad release?"). Interviewers care less about knowing flags and more about understanding the model: what a commit is, what a branch points to, what rewrites history. Below are the 25 most common questions, with answers at the level that makes a good impression.

The questions go from basic to advanced. When answering in an interview, give a short example from your own experience where you can — that's valued more than reciting the docs.

Basic questions

1. What is Git, and how does a distributed version control system differ from a centralized one?

Git is a distributed version control system: it stores the history of changes to a project and lets several people work on it in parallel. In centralized systems (such as SVN) the full history lives on a single server, and a developer only has a working copy. In Git every clone contains the entire history, so commits, branches, browsing history and merges all work locally, without a network.

The practical benefits: high speed, offline work, no single point of failure. A server like GitHub or GitLab is just a team agreement about the "main" copy, not a technical necessity.

2. What are the three areas you work with in Git?

The working directory (files on disk), the index or staging area (a prepared snapshot of the next commit) and the local repository (the .git folder with the history). git add moves changes from the working directory to the index, git commit moves them from the index to the repository.

A nice extra touch is to mention a fourth zone, the remote repository, and the git push and git fetch commands that work with it.

3. Why have an index if you could commit directly?

The index lets you build a commit deliberately: out of ten changed files, commit the three that belong to one task and leave the rest. With git add -p you can even pick individual hunks within a file.

This is the basis of atomic commits: one commit — one logical change. Such a history is easy to read, review, roll back with revert and port with cherry-pick.

4. What is a commit in terms of Git internals?

A commit is an object that stores a reference to a tree — a snapshot of all project files — references to parent commits, the author, the committer, timestamps and the message. It's identified by a SHA-1 hash (newer versions have experimental SHA-256 support) of all its contents.

The key point: Git stores snapshots, not diffs. Unchanged files aren't duplicated — the tree simply points to the same blob. And since the hash depends on the parent, you can't change an old commit without changing the hashes of all subsequent ones.

5. What is a branch, and what is HEAD?

A branch is just a movable pointer to a commit — a file in .git/refs/heads/ with a hash inside. That's why creating a branch in Git is instant and copies nothing. When you make a new commit, the current branch pointer moves to it.

HEAD is a pointer to where you currently are; usually it points to a branch (ref: refs/heads/main). If you check out a specific commit or tag, HEAD points directly at the commit — this is the detached HEAD state.

6. What is detached HEAD, and why is it risky?

It's the state where HEAD points to a commit rather than a branch, for example after git switch --detach v1.0 or git checkout a1b2c3d. You can browse the code and even commit, but new commits don't belong to any branch.

If you then switch to another branch, those commits become unreachable and will eventually be removed by garbage collection. To keep your work, create a branch: git switch -c fix-from-detached. If you've already left, the hash can be found in git reflog.

7. What's the difference between git fetch and git pull?

git fetch downloads new commits and updates remote-tracking branches like origin/main, but doesn't touch your local branches or files. git pull is fetch plus integration: merge by default, or rebase with the --rebase flag or the pull.rebase=true setting.

Experienced developers often run fetch separately, look at git log HEAD..origin/main, and only then decide how to integrate the changes.

8. How does .gitignore work, and why is a file still tracked even though it's listed there?

.gitignore defines patterns for files Git shouldn't offer to add: dependencies, builds, logs, local configs with secrets. The rules apply only to untracked files.

If a file has already been committed, ignoring it has no effect. You need to remove it from the index while keeping it on disk: git rm --cached config.local.php, and commit that removal. git check-ignore -v path helps you find out which rule matches.

Branches, merging and conflicts

9. What is a fast-forward merge?

If the target branch hasn't moved since you branched off, Git simply moves its pointer to the latest commit of the merged branch — no new commit is created. History stays linear.

The --no-ff flag forces a merge commit even in this case, so history shows that a group of commits was a separate feature. The --ff-only flag, conversely, allows only fast-forward and refuses if a real merge is needed.

10. How does a merge conflict happen, and how do you resolve it?

A conflict happens when the same lines of a file were changed in both branches (or a file was deleted in one branch and modified in the other), and Git can't decide automatically. It stops the merge and marks the spots with <<<<<<<, =======, >>>>>>> markers.

git status                 # list of conflicted files
# edit the files, keeping the correct version
git add app.js
git commit                 # for merge; for rebase — git rebase --continue

A good answer also covers prevention: small branches, frequent pull from the main branch, agreed formatting rules. And git merge --abort if you need to back out.

11. How do merge and rebase differ?

merge combines two branches by creating a merge commit with two parents; existing commits don't change, and history honestly reflects parallel work. rebase moves your branch's commits on top of another branch, creating copies with new hashes; the result is a linear history.

The usual rule: rebase to tidy up your own local branch before publishing, merge to integrate into shared branches. Rebasing published commits that others are working on leads to duplicates and confusion.

12. What is interactive rebase, and what is it for?

git rebase -i HEAD~5 opens a list of the last five commits where you choose an action for each: pick — keep, reword — change the message, edit — stop and amend, squash and fixup — fold into the previous one, drop — delete. Lines can be reordered.

A typical scenario: before a pull request, turn "wip", "fix typo", "another fix" into two or three meaningful commits. A handy combo: git commit --fixup=<hash> followed by git rebase -i --autosquash.

13. What does a squash merge do, and when do you choose it?

With a squash merge, all commits of a branch are compressed into a single commit in the target branch (git merge --squash or the button on GitHub/GitLab). The main branch gets one commit per feature.

The upside is a clean main history. The downside is that the detailed history within the feature is lost, and Git doesn't consider the source branch merged, so git branch -d refuses to delete it without -D.

14. What is cherry-pick, and when is it appropriate?

git cherry-pick <hash> applies the changes of one commit to the current branch, creating a new commit with the same content but a different hash. The classic case is porting a bug fix from develop to a release or hotfix branch.

Don't overuse it: the same fix ends up living in two commits, and merging the branches later can cause conflicts. The -x flag adds a reference to the original commit in the message.

Undoing changes and recovery

15. What's the difference between git reset --soft, --mixed and --hard?

Mode	Branch pointer	Index	Working directory
--soft	moves	unchanged	unchanged
--mixed (default)	moves	reset	unchanged
--hard	moves	reset	reset, edits are lost

git reset --soft HEAD~3 is handy for turning the last three commits into one. --hard is dangerous for uncommitted edits: not even the reflog can bring them back.

16. How does git revert differ from git reset?

reset moves the branch pointer back, effectively rewriting history. revert creates a new commit that undoes the changes of the given one, and rewrites nothing.

So for published commits on a shared branch the right answer is revert: teammates' history doesn't break, and the undo itself is visible in the log. For a merge commit you need to specify the mainline parent: git revert -m 1 <hash>.

17. How do you recover commits after an accidental git reset --hard?

With git reflog: it keeps a local history of HEAD and branch movements (by default entries live for about 90 days). Find the entry before the bad command and go back:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# 9f8e7d6 HEAD@{1}: commit: Add payments
git reset --hard 9f8e7d6

An important caveat: the reflog only saves committed work. Changes that never made it into a commit (or at least a stash) can't be recovered with Git.

18. How do you discard changes in a file and unstage it?

The modern commands are git restore app.js (revert the file to the index state) and git restore --staged app.js (unstage it while keeping the edits). Previously you'd use git checkout -- app.js and git reset HEAD app.js; they still work.

19. What is git stash, and what are its pitfalls?

git stash temporarily saves uncommitted changes and cleans the working directory — for example, so you can urgently switch to a hotfix. You get them back with git stash pop or apply.

Pitfalls: untracked files aren't saved by default (you need -u); pop can hit a conflict, in which case the entry isn't removed from the list; and stashes are easy to forget about. For longer work, a commit on a separate branch is better.

Advanced questions and teamwork

20. How do you find the commit that broke a feature?

With git bisect — a binary search through history. You mark a known bad commit and a known good one, and Git checks out the middle of the range until it finds the culprit in log2(N) steps.

git bisect start
git bisect bad                 # the current version is broken
git bisect good v2.3.0         # everything worked here
# test and answer good/bad until Git names the commit
git bisect reset

If you have a test script, the process can be automated: git bisect run npm test.

21. Why is git push --force dangerous, and what should you use instead?

--force overwrites the remote branch with your version, and commits your teammates managed to push disappear from the server. git push --force-with-lease is safer: it overwrites the branch only if the server state matches what you saw on your last fetch.

A force push is fine for your own feature branch after a rebase; for main and other shared branches it's usually blocked by branch protection on the server.

22. Which Git workflows do you know?

GitHub Flow: one main branch that's always deployable, and short-lived feature branches merged via pull request after review and CI. Git Flow: main and develop branches, plus feature/*, release/* and hotfix/*; suits products with versioned releases. Trunk-based development: everyone integrates into trunk very frequently, and unfinished work is hidden behind feature flags.

A strong answer explains the choice: for a web service with continuous deployment Git Flow is usually overkill, while for a library that supports several versions it's justified.

23. What is a pull request, and what gets checked in it?

A pull request (a merge request in GitLab) is a request to merge a branch that goes through code review and automated CI checks before merging. It's a feature of the platform (GitHub, GitLab, Bitbucket), not of Git itself.

A good PR is small, solves one task, has a clear description and is linked to a ticket in the tracker. The reviewer looks at correctness, readability, tests, and whether any stray files or secrets slipped into the PR.

24. What rules do you follow for good commit messages?

A short subject line (up to 50–72 characters) in the imperative mood — "Add email validation", then a blank line and a body explaining "why" rather than "what" (what changed is visible in the diff). Many teams use Conventional Commits: feat:, fix:, docs:, refactor:.

Messages like these let you generate a changelog, quickly find things with git log --grep, and understand the motivation behind changes years later.

25. What would you do if you accidentally pushed a password to the repository?

First — revoke and rotate the secret: it's already compromised even if you delete it a minute later (clones, forks, caches). Then stop tracking the file, add it to .gitignore and, if needed, scrub the history with tools like git filter-repo, followed by a force push and a heads-up to the team.

Here the interviewer is checking your priorities: a candidate who starts by rewriting history and forgets about rotating the key gives the wrong answer.

How to prepare for Git interview questions

The most reliable approach isn't memorizing answers but running every scenario by hand in a test repository: create a conflict and resolve it, do a reset --hard and recover via reflog, squash commits with interactive rebase. Git interviews often include a hands-on task or ask you to draw the commit graph before and after a command — if you've done it yourself, the answer comes easily.

It's also useful to take a short Git quiz to check yourself: try answering without hints what happens to history after git rebase main or git revert HEAD. If you can confidently answer "what changes in the three areas", you've got the fundamentals down.

Summary

A Git interview almost always comes down to three topics: the data model (commits, branches, HEAD, the index), integrating changes (merge, rebase, conflicts, fetch and pull) and safe undo (reset, revert, reflog). Add an understanding of team workflows and pull requests, and you'll cover the vast majority of questions. All these scenarios, including teamwork and advanced tools, are practiced hands-on in the Git course.