Git and Version Control Interview Questions for DevOps
25 Git and Version Control questions with answers for devops roles — 10 easy, 10 medium, 5 hard.
About Git and Version Control
Every pipeline starts with a Git commit. This topic covers branching, merge versus rebase, reset and revert, stash, cherry-pick, tags, hooks and branching strategies such as GitFlow and trunk-based development, along with real recovery scenarios like leaked secrets, lost branches and broken commits on main.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
Git is a distributed version control system that tracks changes to files; every clone has the full history and works offline. GitHub is a hosting service built around Git that adds remote repositories, pull requests, code review, issues and Actions for CI. Alternatives such as GitLab and Bitbucket offer similar features. You can use Git without GitHub, but not the other way round.
02
What is the difference between git fetch and git pull?
git fetch downloads new commits and branches from the remote into remote-tracking branches like origin/main without touching your working files. git pull is fetch followed by merge (or rebase if configured) into your current branch. Fetch is safer when you want to inspect incoming changes first with git log main..origin/main before integrating them.
git stash saves your uncommitted changes and cleans the working directory, so you can switch branches for an urgent fix. git stash list shows saved entries, git stash pop reapplies the latest and removes it, and git stash apply keeps it. Use git stash -u to include untracked files. It is a short-term tool; for longer work, commit on a branch.
git cherry-pick <hash> applies the changes of one specific commit onto your current branch as a new commit. It is useful to bring a hotfix from main into a release branch without merging everything else. Overusing it creates duplicate commits with different hashes and can cause confusing conflicts later, so prefer merging when you need a whole set of changes.
05
What is .gitignore and how do you stop tracking a file that is already committed?
A .gitignore file lists patterns such as node_modules/, *.log or .env that Git should not track. It only affects untracked files, so a file already committed keeps being tracked. To stop tracking it, run git rm --cached <file>, add it to .gitignore and commit. If it held a secret, the old commits still contain it and the secret must be rotated.
06
How do you undo the last commit but keep the changes?
git reset --soft HEAD~1 # undo commit, keep changes staged
git reset HEAD~1 # undo commit, keep changes unstaged
# only fix the message or add a missed file
git add missed-file.txt
git commit --amend
Use these only on commits not yet pushed. For a pushed commit on a shared branch, use git revert instead.
07
How do you create a new branch, push it and set the upstream?
git switch -c feature/payment-retry
# make changes
git add .
git commit -m "Add retry for failed payments"
git push -u origin feature/payment-retry
After -u (set upstream), plain git push and git pull work on this branch without naming the remote. Then open a pull request against main.
08
How do you view the commit history in a compact graph form?
git log --oneline --graph --decorate --all
# last 10 commits by one author
git log --oneline -10 --author="Ravi"
# commits touching one file, with diffs
git log -p -- src/app.py
# who changed each line
git blame src/app.py
--graph draws branch and merge lines, and --decorate shows branch and tag names next to commits.
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0
# push all tags
git push origin --tags
# list and inspect
git tag -l "v1.*"
git show v1.2.0
Annotated tags (-a) store author, date and message and are preferred for releases. Many CI pipelines trigger production builds on tags matching v*.
10
How do you make your commits and pull requests easy for teammates to review?
I keep each pull request focused on one change and small enough to review in about fifteen minutes. Commits have clear messages saying what and why. The description explains the problem, the approach, how I tested it and any risk or rollback step. I run linters and tests locally first, and I reply to every review comment, even if just to say done.
11
What is the difference between git merge and git rebase?
Merge joins two branches with a merge commit and keeps the true history, including when work happened in parallel. Rebase replays your commits on top of the target branch, giving a clean linear history but new commit hashes. Rebase local feature branches to stay current, but never rebase commits others have already pulled, because it rewrites shared history.
HEAD normally points to a branch name. In detached HEAD, it points directly to a commit, for example after git checkout <hash> or checking out a tag. You can look around and even commit, but new commits belong to no branch and can be lost when you switch away. To keep them, create a branch with git switch -c new-branch.
All three move the current branch pointer to another commit. --soft keeps your changes staged, useful for recombining commits. --mixed, the default, keeps changes in the working directory but unstaged. --hard discards changes in both staging and working directory, so uncommitted work is lost. Lost commits can usually still be found with git reflog for a while.
14
What is the difference between git revert and git reset?
git revert creates a new commit that undoes the changes of an earlier commit, leaving history intact, so it is safe on shared branches like main. git reset moves the branch pointer backwards and removes commits from the branch history, which is fine locally but forces others to deal with rewritten history if already pushed. Use revert for anything already public.
15
What are Git hooks and how are they used in DevOps?
Hooks are scripts Git runs at events such as pre-commit, commit-msg and pre-push on the client, or pre-receive on the server. Teams use them to run linters, format code, block secrets or enforce commit message formats before code leaves a laptop. Client hooks are not shared by default, so tools like pre-commit or Husky manage them, and CI repeats the checks.
Git marks conflicting files and inserts markers showing both versions. Open each file, decide the correct final code, often combining both sides after talking to the other author, and remove the markers. Then git add the files and finish with git commit or git rebase --continue. Run tests before pushing, because a conflict resolved without errors can still break logic.
17
You deleted a local branch that had unmerged commits. How do you recover it?
Git keeps unreferenced commits for a while. Run git reflog to see recent HEAD positions and find the last commit of that branch, or check the hash printed when you deleted it. Then recreate the branch with git branch feature-x <hash>. Reflog is local only, so this works on the same machine, and entries expire after about 90 days by default.
18
You pushed a broken commit to the shared main branch and the build is failing. What do you do?
First restore a green main quickly: run git revert <hash> and push, which adds an undo commit without rewriting history that others have pulled. Tell the team in the channel. Then fix the issue on a branch with a proper pull request and tests. Avoid git reset with force push on main; branch protection rules should block it anyway.
19
How do you squash your last three commits into one?
git rebase -i HEAD~3
# in the editor, keep the first line as pick
# and change the other two to squash (or s)
pick a1b2c3 Add login API
squash d4e5f6 Fix typo
squash 789abc Add tests
# alternative without the editor
git reset --soft HEAD~3
git commit -m "Add login API with tests"
If the branch was already pushed, update it with git push --force-with-lease.
20
Tell me about a time you disagreed with a code review comment.
Situation: a reviewer asked me to replace a simple retry loop in our deploy script with a heavy external library. Task: I felt it added risk. Action: I explained my reasoning, shared a small benchmark and failure tests, and asked what concern they had; it was about backoff. Result: I added exponential backoff to my version, they approved, and we documented the pattern.
GitFlow uses long-lived develop and main branches plus feature, release and hotfix branches; it suits scheduled releases but causes big merges. Trunk-based development has everyone merge small changes into main at least daily, with short-lived branches and feature flags to hide unfinished work. It suits continuous delivery and is what high-performing DevOps teams usually prefer, but needs strong automated tests.
22
A developer accidentally pushed an AWS access key to a public repository. What do you do?
Treat the key as compromised immediately: deactivate and rotate it in IAM, then check CloudTrail for misuse. Removing it from history comes second, using git filter-repo or BFG and a force push, and asking everyone to re-clone. Then prevent repeats with secret scanning in CI, pre-commit hooks like gitleaks and storing secrets in a vault or secrets manager instead of code.
23
Your repository has become huge because of binary files and clones are very slow. How do you fix it?
Short term, CI can use shallow clones with --depth 1 and partial clone filters. For future binaries, move them to Git LFS or an artefact store such as S3 or Nexus. To shrink existing history, use git filter-repo to remove the large files, coordinate a force push and ask everyone to re-clone. Add size checks in pre-receive hooks to prevent recurrence.
24
Two features are in main but only one must go to production this week. How do you manage this?
The cleanest approach is feature flags: both features merge to main, but the unfinished one stays switched off in production, so deployment is separated from release. Without flags, you cut a release branch and revert or exclude the second feature, which is error prone. For the future, keep branches short-lived and agree with product on flag-based releases.
25
How do you use git bisect to find the commit that introduced a bug?
git bisect start
git bisect bad # current commit has the bug
git bisect good v1.4.0 # last known good tag
# Git checks out a middle commit; test it, then mark it
git bisect good # or: git bisect bad
# repeat until Git prints the first bad commit
git bisect reset
# automate with a test script
git bisect run ./run-tests.sh
Bisect is a binary search, so 1000 commits need about 10 tests.
Frequently asked questions
How important is Git and Version Control in DevOps interviews?
Every pipeline starts with a Git commit. This topic covers branching, merge versus rebase, reset and revert, stash, cherry-pick, tags, hooks and branching strategies such as GitFlow and trunk-based development, along with real recovery scenarios like leaked secrets, lost branches and broken commits on main.
How should I use the Git and Version Control sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.