Interview questions & answers

Git & Version Control interview questions & answers

What are the most common Git & Version Control interview questions?

Git is a distributed version control system that tracks changes to source code, letting multiple developers collaborate and maintain a full history of a project. Every clone is a complete repository with its own history, enabling offline work and flexible branching. Interviews test the working tree and staging area, branching and merging, rebase versus merge, conflict resolution, and remote collaboration.

Practise in a free AI mock interview Create my free profile

Updated 2026-06-18 · 15 real, commonly-asked questions with answers.

Key takeaways

Git is a distributed version control system that tracks changes to source code, letting multiple developers collaborate and maintain a full history of a project.
Core areas to revise for Git & Version Control: Working tree & staging area, Branching & merging, Rebase vs merge, Reset vs revert, Remotes (fetch, pull, push).
This guide answers 15 of the most-asked Git & Version Control interview questions — rehearse them in OnJob's free AI mock interview.

Working tree & staging areaBranching & mergingRebase vs mergeReset vs revertRemotes (fetch, pull, push)Conflict resolutionStashing & cherry-pickHEAD & history

Top 15 Git & Version Control interview questions

Q1.What is the difference between Git and GitHub?

Git is the distributed version control system that runs locally and tracks your code's history. GitHub is a cloud-based hosting service for Git repositories that adds collaboration features like pull requests, issues, code review, and access control on top of Git. You can use Git without GitHub; GitHub (or GitLab, Bitbucket) is one place to host and share Git repos.

Q2.What are the three states of a file in Git?

A file can be modified (changed in the working directory but not yet staged), staged (marked in the staging area, or index, to go into the next commit), or committed (safely stored in the local repository's history). The git add command moves changes from modified to staged, and git commit moves staged changes into the committed state.

Q3.What is the difference between git merge and git rebase?

git merge combines two branches by creating a new merge commit that ties their histories together, preserving the exact history but adding extra commits. git rebase moves or replays your branch's commits on top of another branch, producing a linear history without a merge commit but rewriting commit hashes. Merge keeps history truthful; rebase keeps it clean. Never rebase commits that others have already pulled.

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

git fetch downloads new commits and refs from a remote into your local tracking branches but does not change your working branch, letting you review changes first. git pull is effectively git fetch followed by git merge (or rebase), which downloads and immediately integrates the changes into your current branch. Pull combines the two steps; fetch is the safer, inspect-first option.

Q5.What is the difference between git reset and git revert?

git revert creates a new commit that undoes the changes of a previous commit, preserving history, which is safe for shared branches. git reset moves the branch pointer to an earlier commit, optionally changing the staging area and working directory (--soft, --mixed, --hard), effectively rewriting history. Use revert on public history; use reset to fix local, unpushed commits.

Q6.What does git stash do?

git stash temporarily saves your uncommitted changes (both staged and unstaged) and reverts your working directory to a clean state, so you can switch branches or pull without committing half-done work. You reapply the saved changes later with git stash pop (which removes it from the stash) or git stash apply (which keeps it). It is handy for context switching.

Q7.What is a merge conflict and how do you resolve it?

A merge conflict occurs when two branches change the same lines of a file (or one edits a file the other deleted) and Git cannot automatically reconcile them. Git marks the conflicting regions in the file with conflict markers. You resolve it by editing the file to the desired result, removing the markers, staging it with git add, and completing the merge with a commit.

Q8.What is the difference between git reset --soft, --mixed, and --hard?

All three move the branch pointer to a target commit but differ in what else they touch. --soft moves the pointer only, leaving your staged changes and working directory intact. --mixed (the default) also resets the staging area but keeps the working directory. --hard resets the pointer, staging area, and working directory, permanently discarding uncommitted changes.

Q9.What is HEAD in Git?

HEAD is a pointer to the current commit you have checked out, usually pointing to the tip of the current branch. When you commit, the branch and HEAD advance to the new commit. A detached HEAD state occurs when you check out a specific commit instead of a branch, meaning new commits are not on any branch and can be lost if you switch away.

Q10.What is the difference between git clone, git fork, and git branch?

git clone copies an entire remote repository to your local machine. A fork is a GitHub (not core Git) action that creates your own server-side copy of someone else's repository so you can contribute via pull requests. git branch creates a new line of development within a repository. Clone copies a repo locally; fork copies it on the server; branch diverges work inside one repo.

Q11.What is a detached HEAD state?

A detached HEAD occurs when HEAD points directly to a specific commit rather than to a branch, which happens when you check out a commit hash or tag. You can look around and even make commits, but those commits do not belong to any branch and become unreachable (and eventually garbage-collected) once you switch away unless you create a branch to keep them.

Q12.What does git cherry-pick do?

git cherry-pick applies the changes introduced by one or more specific commits from another branch onto your current branch, creating new commits with the same changes but new hashes. It is useful for pulling a single bug fix from one branch into another without merging the entire branch. Conflicts are resolved the same way as in a merge.

Q13.How do you undo the last commit?

If the commit is local and unpushed, git reset --soft HEAD~1 removes the commit but keeps its changes staged so you can recommit, while git reset --hard HEAD~1 discards both the commit and its changes. If the commit was already pushed and shared, prefer git revert HEAD, which adds a new commit that undoes it without rewriting shared history.

Q14.What is the difference between a fast-forward and a three-way merge?

A fast-forward merge happens when the target branch has not diverged, so Git simply moves the branch pointer forward to the source branch's tip with no new commit. A three-way merge happens when both branches have new commits since they diverged; Git combines them using their common ancestor and creates a new merge commit. Fast-forward is linear; three-way produces a merge commit.

Q15.What is .gitignore used for?

A .gitignore file lists patterns for files and directories that Git should not track, such as build artifacts, dependency folders like node_modules, log files, and secrets. Matching untracked files are excluded from status and commits. Note that .gitignore only affects untracked files; to stop tracking a file already committed you must remove it from the index with git rm --cached.

Free AI mock interview

Practise Git & Version Control out loud

Reading answers is step one. Rehearse them in OnJob's free AI mock interview, get instant feedback, then apply to AI-matched jobs in one click.

Start a free mock interview Create my free profile