Git is used by every software team, so Git questions appear in developer, DevOps and tester interviews. These Git interview questions cover repositories, commits and branches for freshers, then merge vs rebase, resolving conflicts, undoing changes, branching strategies and recovering lost work for experienced developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Git is a distributed version control system that tracks changes to files, so every developer has a full copy of the project history and can work offline. GitHub, GitLab and Bitbucket are hosting platforms for Git repositories that add collaboration features such as pull requests, code review, issues and CI/CD.
The working directory holds your files as you edit them.
The staging area (index) holds the changes you have chosen for the next commit with git add.
The repository stores committed snapshots with git commit.
This lets you commit related changes together even if you edited many files.
git fetch downloads new commits and branches from the remote but does not change your working branch, so you can review changes first. git pull runs fetch and then merges (or rebases, if configured) the remote branch into your current branch.
git clone copies a remote repository, git status shows changed files, git add stages changes, git commit -m saves a snapshot, git pull brings in remote changes, git push uploads commits, git switch -c creates and switches to a branch, git log shows history and git diff shows changes. git init creates a new repository.
.gitignore lists files and patterns Git should not track, such as node_modules, build output, log files, .env files with secrets and editor settings.
Patterns support wildcards, directories and negation with !.
It only affects untracked files; a file already committed must be removed from the index with git rm --cached to stop tracking it.
A short summary line under about 50 to 72 characters in the imperative mood, such as "Fix login redirect after password reset", then a blank line and a body explaining what changed and why if needed.
Each commit should contain one logical change.
Many teams use Conventional Commits, such as feat:, fix: and docs:, which can generate changelogs automatically.
git log shows commits, with useful options such as --oneline, --graph, --author, -p (show changes) and -- path for one file. git diff shows unstaged changes, git diff --staged shows staged changes, git show <commit> shows one commit, and git blame shows who last changed each line, which helps understand why code was written.
git branch lists branches, git switch -c feature/login creates a branch and switches to it (git checkout -b does the same in older Git), git switch main goes back, and git branch -d deletes a merged branch. Branches are cheap pointers to commits, so creating one for every feature or fix is normal.
HEAD is a pointer to the commit you currently have checked out, usually through the current branch, so it moves forward as you commit.
HEAD~1 means the parent commit and HEAD~3 three commits back.
If you check out a specific commit instead of a branch, you are in a detached HEAD state.
A remote is a named link to another copy of the repository. origin is the default name for the repository you cloned from. When you fork a project, upstream conventionally refers to the original repository, so you fetch updates from upstream and push to your fork (origin). git remote -v lists remotes, and an upstream branch is the remote branch your local branch tracks.
You create a branch, commit your changes, push the branch and open a pull request (merge request on GitLab) describing what changed and why. Automated checks run tests and linting, teammates review the code and request changes, you push fixes, and once approved the PR is merged into the main branch, often with a squash or merge commit, and the branch is deleted.
Applied problems, trade-offs and questions about your own projects.
Merge combines branches by creating a merge commit, preserving the exact history of both.
Rebase moves your commits on top of another branch, rewriting them to create a straight, linear history.
I rebase my own local feature branch to keep it up to date, but never rebase shared branches that others have pulled, because it rewrites history they depend on.
Git marks conflicting sections in the files with <<<<<<<, ======= and >>>>>>>.
I open each file, decide what the correct combined code should be, remove the markers, then run tests, stage the files with git add and complete the merge or continue the rebase.
Talking to the other developer helps when it is unclear which change is right.
git revert creates a new commit that undoes an earlier commit, which is safe for shared branches. git reset moves the branch pointer back: --soft keeps changes staged, --mixed keeps them unstaged and --hard discards them, so it should only be used on local commits. git restore discards changes in the working directory or unstages files.
git stash saves uncommitted changes temporarily and cleans the working directory, so you can switch branches, for example to fix an urgent bug. git stash pop reapplies the latest stash and removes it, git stash apply keeps it, and git stash list shows saved stashes. Including -u stashes untracked files too.
git rebase -i lets you rewrite a series of local commits before sharing them: reorder commits, squash several into one, reword messages, edit a commit or drop one.
It is used to turn messy work-in-progress commits into a clean history before opening a pull request.
It rewrites commit hashes, so it should only be used on commits that others have not based work on.
A fast-forward merge simply moves the branch pointer forward when there are no diverging commits, leaving a linear history.
A merge commit (--no-ff) records that a branch was merged and keeps all its commits.
A squash merge combines all the branch's commits into a single new commit on the target branch, giving a clean history but losing individual commits.
git commit --amend replaces the last commit with a new one, letting you fix the message or add forgotten files that you have staged. git commit --amend --no-edit keeps the message. Because it creates a new commit hash, you should only amend commits that have not been pushed, or force-push with --force-with-lease on your own branch.
A tag is a fixed name for a specific commit, used to mark releases such as v2.1.0.
Annotated tags (git tag -a v2.1.0 -m "Release 2.1.0") store the author, date and message and are recommended for releases; lightweight tags are simple pointers.
Tags must be pushed explicitly with git push origin v2.1.0.
Versions usually follow semantic versioning.
Detached HEAD means you checked out a commit, tag or remote branch directly instead of a local branch, so new commits do not belong to any branch and can be lost when you switch away.
If you made commits you want to keep, create a branch at that point with git switch -c new-branch.
If you switched away already, git reflog shows the commit hash.
Hooks are scripts Git runs automatically at certain events, such as pre-commit (before a commit is created), commit-msg (to check the message format) and pre-push.
Teams use them to run linters, formatters and quick tests, often managed with Husky and lint-staged in JavaScript projects or the pre-commit framework.
Server-side checks in CI are still needed because local hooks can be skipped.
First treat the secret as compromised and rotate it immediately, because it may already have been copied.
Then remove it from the files, and if it was pushed, rewrite history with git filter-repo or BFG and force-push, and ask collaborators to re-clone.
Prevent repeats with .gitignore, secret scanning tools such as gitleaks in pre-commit hooks and GitHub push protection.
System design, deep internals, leadership and tough follow-ups.
GitHub Flow uses a main branch that is always deployable and short-lived feature branches merged through pull requests, which suits continuous deployment.
Git Flow has develop, feature, release and hotfix branches, which suits scheduled releases.
Trunk-based development has everyone merge small changes to main frequently, using feature flags to hide unfinished work, which suits mature CI/CD.
git reflog lists where HEAD and branches have pointed recently, including commits no longer on any branch.
I find the commit hash in the reflog and recreate the branch with git branch recovered <hash>, or reset to it.
Reflog entries are kept for about 90 days by default, so most mistakes can be undone.
git cherry-pick applies a specific commit from one branch onto another, for example copying a bug fix to a release branch. git bisect finds the commit that introduced a bug using binary search: you mark a known good and a known bad commit, and Git checks out commits in between for you to test, or runs a test script automatically, until it identifies the culprit.
Git is a content-addressable store of objects identified by their SHA hash: blobs store file contents, trees store directory listings pointing to blobs and other trees, commits point to a tree, parent commits, author and message, and annotated tags point to commits.
Branches and tags are simply files containing a commit hash.
Because identical content has the same hash, Git stores it only once.
Use partial clone (--filter=blob:none) to download file contents only when needed, shallow clones (--depth) for CI, sparse checkout to check out only the folders you work on, Git LFS for large binary files such as images and videos, and git maintenance for background optimisation. Monorepo tools add build caching on top.
git worktree lets you check out several branches of the same repository into different folders at the same time, sharing one .git store.
You can, for example, fix an urgent bug on main in a second folder without stashing or committing unfinished work in your feature branch.
It is lighter than cloning the repository again.
Anyone can set any name and email in Git, so signatures prove that a commit really came from a trusted person or system.
Commits and tags can be signed with GPG, SSH keys or S/MIME (git config commit.gpgsign true), and platforms such as GitHub show them as verified.
Some organisations require signed commits on protected branches as part of supply chain security.
Use branch protection rules or rulesets: require pull requests with at least one approval, require status checks such as tests and linting to pass, require branches to be up to date, block force pushes and deletion, optionally require signed commits and linear history, and use CODEOWNERS so the right people automatically review changes to their areas.
See all DevOps Engineer interview questions, covering Linux, Git, Docker, Kubernetes, CI/CD (GitHub Actions, Jenkins) and more.