Git Interview Questions

Git Interview Overview

Strong Git answers connect the working directory, staging area, and repository to everyday commands like status, add, commit, and push. Be ready to explain what happens when you merge, rebase, cherry-pick, or reset, and how remotes fit into team workflows.

Mid-level and senior interviews often probe conflict resolution, history rewriting, and release strategies. Practice describing trade-offs: merge commits vs fast-forward, rebase vs merge, and when to use interactive rebase, revert, or reset --hard vs --soft.

Git Interview Cheatsheet

Quick answers you can expand in a real interview.

15 Git Interview Questions with Answers

Use the short version first, then offer trade-offs if the interviewer wants depth.

1. What is Git and how does it differ from centralized VCS like SVN?

Git is a distributed version control system where every clone is a full repository with complete history. Unlike SVN, which relies on a central server for most operations, Git commits locally first and syncs via push/pull. That enables offline work, cheap branching, and flexible workflows like feature branches and forks.

2. Explain the difference between git add, git commit, and git push.

git add copies changes from the working directory into the staging area (index). git commit snapshots the staged content into the local repository with a message and parent commit. git push uploads local commits to a remote so teammates can pull them. Add and commit are local; push is how you share.

3. What is the staging area and why does Git use it?

The staging area (index) sits between your working tree and commits. It lets you craft commits selectively—stage part of a file or only some files in a large change set. That supports small, focused commits and review-friendly history instead of one giant commit per save.

4. Difference between merge and rebase?

Merge combines two histories, often creating a merge commit that preserves both branch timelines. Rebase replays your commits on top of another branch, producing a linear history. Rebase is cleaner for feature branches before merge, but rewriting shared public history causes pain for collaborators.

5. What is a fast-forward merge?

A fast-forward merge moves the branch pointer forward when the target branch has no divergent commits—no merge commit is created. Git simply points main at the tip of the feature branch. Use it when you want a straight line of history and the feature branch can be discarded afterward.

6. How do you resolve a merge conflict?

Git marks conflicted files with conflict markers. Open each file, choose the correct code, remove markers, then git add the resolved files and complete the merge or rebase with git commit or git rebase --continue. Tools like git mergetool or IDE merge UIs speed this up on large conflicts.

7. What does git reset --soft, --mixed, and --hard do?

--soft moves HEAD but keeps staging and working tree unchanged—good for redoing a commit message. --mixed (default) resets staging too but keeps working tree edits. --hard discards staging and working tree changes to match HEAD—destructive and should be used only when you are sure.

8. Difference between git revert and git reset?

git revert creates a new commit that undoes a prior commit—safe for shared history because nothing is rewritten. git reset moves branch pointers and optionally discards commits locally. Reset is fine on private branches; revert is the team-safe way to undo published work.

9. What is git stash and when would you use it?

git stash temporarily shelves uncommitted changes so you can switch branches or pull cleanly. Run git stash push, do other work, then git stash pop or apply to restore. Use named stashes and git stash list when juggling multiple WIP items during hotfix interruptions.

10. Explain git cherry-pick.

Cherry-pick applies the patch from a specific commit onto your current branch as a new commit with a new hash. It is useful for backporting a bug fix from main to a release branch without merging entire branches. Watch for conflicts if the surrounding code diverged.

11. What is git bisect used for?

git bisect performs a binary search across commit history to find which commit introduced a bug. You mark a bad commit and a known good commit, then Git checks out middle commits for you to test until it isolates the culprit. It saves hours on regressions in long histories.

12. How do branches and tags differ?

Branches are movable pointers to commits—you advance them with new work. Tags are usually immutable labels for releases like v1.2.0. Both are refs, but tags document points in history while branches represent ongoing lines of development.

13. What is a detached HEAD state?

HEAD points directly at a commit instead of a branch name, often after checking out a tag or old commit. New commits exist but no branch tracks them—they can be lost when you switch away unless you create a branch: git switch -c rescue-branch.

14. How does .gitignore work and what are common pitfalls?

.gitignore lists patterns for untracked files Git should skip. Already tracked files stay tracked even if later ignored—you must git rm --cached them. Pitfalls include ignoring too broadly (build artifacts vs secrets), platform-specific paths, and forgetting global gitignore for editor files.

15. Describe a solid Git workflow for a team using pull requests.

Create a short-lived feature branch from main, commit in small logical chunks with clear messages, push and open a PR, address review, then merge via squash or merge commit per team policy. Rebase onto main before merge to reduce conflicts. Protect main with required reviews and CI.

Common Mistakes

• Using git reset --hard on shared branches instead of revert.
• Rebasing commits that others already pulled.
• Making giant commits that mix unrelated changes.
• Not pulling/rebase before push and surprise conflicts at merge time.

Key Takeaways

• Explain the three-tree model before listing commands.
• Know merge vs rebase trade-offs for team workflows.
• Practice conflict resolution and interactive rebase scenarios.
• Describe safe undo strategies: revert for public, reset for local.