Git interview questions for DevOps roles should test more than memorized commands. A strong candidate can explain what happened in the repository, choose the least risky recovery path, and keep a release moving without hiding history or breaking collaboration.
Quick takeaway: For DevOps interviews, Git is a workflow and incident-recovery skill. Focus on branching, rebasing, merge conflicts, cherry-picks, revert vs reset, reflog recovery, and safe release hygiene instead of asking trivia about every flag.
This guide narrows the broad interview cluster into Git-specific operational scenarios. Use it with broader prep like junior DevOps interview questions, middle DevOps interview questions, and release management interview questions.
How to Use These Git Interview Questions
Good Git interviews ask for a diagnosis, a command, and the tradeoff. The best answers usually include what the candidate would check before running the command, what could go wrong, and how they would communicate the change to the team.
| Signal | Weak answer | Strong DevOps answer |
|---|---|---|
| Merge conflict | “I fix the file and commit.” | Explains conflict source, tests the resolved state, preserves review context, and avoids mixing unrelated changes. |
| Bad commit on shared branch | “I reset it.” | Chooses revert for shared history, explains when reset is safe, and mentions force-push risk. |
| Hotfix needed | “I make a branch.” | Creates a focused hotfix branch, cherry-picks only required commits, validates build, and keeps release notes clear. |
| Lost work | “Git deleted it.” | Checks reflog/stash/branch tips before declaring work lost. |
Core Git Concepts Candidates Should Explain
The baseline is branch and commit literacy. The official Git book explains branches as movable pointers to commits. Candidates do not need textbook wording, but they should understand that most Git workflows are about moving, combining, or protecting commit history.
- A branch is a pointer to a commit, not a separate copy of the repository.
- HEAD points to the currently checked-out commit or branch reference.
- A merge preserves both lines of history; a rebase rewrites commits on top of another base.
- A tag should usually identify a release or important immutable point, not a moving target.
- A remote-tracking branch is local information about a remote branch, not the remote branch itself.
Branching and Merge Questions
1. What is the difference between merge and rebase?
A merge creates a commit that joins two histories. A rebase rewrites local commits so they appear on top of a new base. The Git book’s rebasing chapter is the source to review here. In a DevOps setting, the practical rule is: rebase your own unpublished work if it helps clarity; avoid rebasing shared branches unless the team explicitly agrees.
2. How would you resolve a merge conflict safely?
First identify the files and the intent of both sides. Then resolve the conflict, run the relevant tests or checks, inspect the diff, and commit the resolution. A strong candidate also says what they would not do: blindly accept “ours” or “theirs” on production code without understanding what was lost.
git status
git diff
# edit conflicted files
git add path/to/file
git commit3. When is a force push acceptable?
A force push is acceptable for a personal branch when nobody else depends on that history, or when the team has explicitly coordinated the rewrite. It is dangerous on shared release, main, or integration branches. A safer command is usually force-with-lease because it refuses to overwrite remote work you have not seen.
git push --force-with-lease origin feature/my-branchUndo and Recovery Questions
4. Revert vs reset: which one should you use?
Use revert when the bad commit is already shared, because it creates a new commit that reverses the change. Use reset only when you are moving your own local branch pointer and understand the impact. The Git book’s undoing chapter is a useful source for this distinction.
| Situation | Safer choice | Reason |
|---|---|---|
| Bad commit already on main | git revert | Preserves shared history and creates an auditable fix. |
| Local commit not pushed | git reset may be fine | Only your local branch history changes. |
| Need to recover lost branch tip | git reflog | Finds previous HEAD positions before cleanup. |
| Wrong file staged | git restore --staged | Unstages without deleting work. |
5. How do you recover a commit after a bad reset?
Check the reflog. The git reflog documentation describes how Git records updates to branch tips and HEAD. In an interview, a good answer includes finding the previous commit, creating a branch from it, and verifying the recovered work before pushing anything.
git reflog
git checkout -b recover-work HEAD@{1}
git log --oneline --decorate -5Release and Hotfix Questions
6. How would you move one fix from develop to a release branch?
Use cherry-pick when the release branch needs one specific commit, not the entire feature history. The git cherry-pick documentation is the command reference. The candidate should also mention build verification and a follow-up merge strategy so the hotfix does not disappear from the main development line.
git checkout release/2026-06
git cherry-pick abc1234
# run tests/build
git push origin release/2026-067. What should be in a release branch policy?
- Only release fixes, version updates, and approved low-risk changes go in.
- Every change has a ticket, reviewer, and build result.
- Hotfixes are back-merged or forward-merged according to a documented rule.
- Tags are created from the tested release commit, not from a developer laptop guess.
Practical Git Troubleshooting Questions
| Question | What a strong answer should include |
|---|---|
| A deployment pulled the wrong code. What do you check first? | Commit SHA, tag, branch, CI checkout ref, artifact version, and deployment logs. |
| A teammate force-pushed over your work. What now? | Stop pushing, fetch carefully, inspect reflog/local branches, recover commits, coordinate before rewriting again. |
| A PR contains unrelated changes. How do you clean it? | Interactive rebase or new clean branch, but only before merge and without rewriting shared work unexpectedly. |
| A secret was committed. Is deleting the commit enough? | No. Rotate the secret, remove it from history if needed, and treat the old secret as compromised. |
If the interview also covers scripting or configuration management, pair these Git scenarios with language-specific prep such as Python DevOps interview questions or Ansible interview questions.
FAQ
These questions help separate Git memorization from the operational judgment expected in DevOps roles.
What Git topics matter most in DevOps interviews?
Branching strategy, merge conflicts, revert vs reset, rebase safety, cherry-picks, release tags, and recovery with reflog matter most. The interviewer usually wants to know whether you can protect shared history and unblock delivery.
Should I say rebase is better than merge?
No. Rebase and merge solve different problems. Rebase can clean up local history, while merge is often safer for preserving shared context. A good answer explains the tradeoff.
What is the safest way to undo a bad commit on main?
Use git revert in most shared-branch situations. It creates a new commit that reverses the change without rewriting history that other people may already have pulled.
Why do DevOps teams care about Git tags?
Tags give releases a stable reference. They help connect source code, build artifacts, deployments, and rollback notes to the same commit.
How should I practice Git interview scenarios?
Create a throwaway repository and practice conflicts, cherry-picks, reverts, resets, reflog recovery, and release tagging. Explain each step out loud, including the risk you are avoiding.
Leave a Reply