You use Git every day. You commit, you push, you open pull requests, and once in a while you paste a scary command from Stack Overflow and hope it works. Then the interviewer asks the difference between git reset and git revert, or how you would recover a commit you just deleted with reset --hard, and you realize that "using Git" and "understanding Git" are not the same thing.

That gap is exactly what Git interviews probe. Almost everyone can commit and push; far fewer can explain the three areas a change moves through, why rebase rewrites history, or what the reflog is for. The questions below are the ones that actually come up, grouped from the fundamentals you must not fumble to the recovery scenarios that separate confident engineers from nervous ones. Every answer is written the way you would say it out loud, with a note on what the interviewer is really checking, and every command output here came from running it on real Git.

How Git Interviews Actually Work

Git questions rarely get a dedicated round. They surface inside a developer or DevOps interview, in three shapes.

Rapid fundamentals. The difference between git and GitHub, what staging is, fetch versus pull. One or two sentences each.

"Explain the difference." Merge versus rebase, reset versus revert, soft versus hard. These are the heart of Git interviews because the commands look similar and behave very differently, so they reveal whether you understand what is happening underneath.

Recovery scenarios. You committed to the wrong branch, you pushed a secret, you reset --hard and lost a commit. These are the most senior-discriminating, because the panic answer and the calm answer are very different, and only one of them keeps the work.

A useful anchor before the questions: almost everything in Git comes back to two ideas. First, a change moves through three areas (working directory, staging area, repository). Second, a commit is an immutable snapshot with a unique hash, and branches are just pointers to commits. Tie an answer back to one of those and you will sound like someone who understands Git, not someone reciting commands. If the basics feel shaky, Git for beginners is a clean reset.

Fundamentals

Q1. What is the difference between Git and GitHub?

Git is the version control system: a tool that runs locally and tracks changes to your code. GitHub is a hosting platform for Git repositories, adding collaboration features like pull requests, issues, and access control on top. The one-line version that lands: Git is the tool, GitHub is a place to put Git repositories and collaborate around them, and you can use Git with no GitHub at all. People blur these constantly, so being crisp here sets a good tone. Our Git vs GitHub vs GitLab breakdown is worth a read if you want the full comparison.

What they're really testing: that you understand Git works independently of any hosting service.

Q2. How is Git different from a centralized version control system like SVN?

Git is distributed: every clone is a full repository with the complete history, so you can commit, branch, view history, and diff entirely offline. A centralized system like SVN keeps the history on a single server, and most operations need a connection to it. The practical payoffs of distributed: there is no single point of failure, branching and merging are cheap and local, and you only touch the network when you explicitly push or pull. That independence is the whole reason Git won.

Q3. What are the three areas in Git?

The working directory (your actual files), the staging area or index (changes you have marked for the next commit), and the repository (the committed history). A change moves working directory to staging with git add, then staging to repository with git commit. You can watch a file move through them:

$ git status -s
?? app.txt          # untracked, in the working directory only
$ git add app.txt
$ git status -s
A  app.txt          # staged, ready to commit
# (after commit, then editing it again)
$ git status -s
 M app.txt          # modified in the working directory, not yet staged

What they're really testing: the staging area is the concept beginners miss, and it explains add versus commit, partial commits, and most of git reset.

Q4. What is the difference between git add and git commit?

git add moves changes into the staging area, marking what will go into the next commit. git commit takes whatever is staged and records it permanently in the repository as a new snapshot. The reason the two are separate is control: staging lets you build a commit deliberately, even committing only some of your changes while leaving others for a later commit. "Add stages, commit saves" is the short answer; mentioning that you can stage selectively shows real use.

Q5. What do the short codes in git status mean?

In git status -s, each line has a two-column code: the left column is the staging area, the right is the working directory. So ?? is untracked, A is a newly staged file, M is modified but not staged, M is modified and staged, and MM is staged then modified again. Reading that two-column format fluently is a small but real signal, because it is how you quickly see what is about to be committed versus what is not.

Q6. What is a commit, really?

A commit is an immutable snapshot of your entire tracked tree at a point in time, identified by a hash (a SHA-1, with Git moving toward SHA-256) computed from its content plus metadata. It also points to its parent commit (or parents, for a merge), which is what forms the history. Two things worth saying: a commit stores a snapshot, not a diff (Git computes diffs on the fly), and the hash is what makes history tamper-evident, since changing anything changes every hash after it. For the deeper model, how Git works is a good read.

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

git fetch downloads new commits and refs from the remote but does not touch your working branch, so you can inspect what changed before integrating it. git pull is git fetch followed by a merge (or a rebase, if configured) into your current branch, in one step. The distinction interviewers want: fetch is safe and read-only, pull changes your working branch and can produce conflicts. Experienced users often fetch first to see what is coming before they pull.

Q8. What is .gitignore, and what belongs in it?

.gitignore lists patterns for files Git should not track: build artifacts, dependency folders (node_modules), local environment files, secrets, and editor cruft. The point is to keep the repository to source, not generated or machine-specific files. The senior addition: .gitignore only affects untracked files, so if you have already committed something, adding it to .gitignore will not remove it, you have to git rm --cached it first. And secrets should never have been committed in the first place, which is Q26.

Intermediate

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

Both integrate changes from one branch into another, but differently. Merge creates a new merge commit that ties the two histories together, preserving exactly what happened. Rebase replays your branch's commits on top of the target branch, producing a linear history as if you had branched from the latest point. So merge preserves history and is non-destructive; rebase rewrites it for a cleaner line. The rule I follow: rebase your own local feature branch to tidy it before sharing, but never rebase commits others have already pulled. KodeKloud's guide to the most confusing Git commands covers this pair well.

Q10. What is a fast-forward merge versus a three-way merge?

A fast-forward merge happens when the target branch has not moved since you branched, so Git just slides the branch pointer forward, with no merge commit needed. A three-way merge happens when both branches have new commits, so Git combines them using their common ancestor and creates a merge commit. The practical upshot: fast-forward keeps history linear, while a real divergence produces a merge commit. You can force a merge commit even when fast-forward is possible with --no-ff, which some teams do to keep feature boundaries visible.

Q11. How do you resolve a merge conflict?

A conflict happens when two branches change the same lines and Git cannot decide which wins, so it stops and marks the file. The markers are explicit:

$ git merge feature
CONFLICT (add/add): Merge conflict in shared.txt
$ cat shared.txt
<<<<<<< HEAD
main change
=======
feature change
>>>>>>> feature
$ git status -s
AA shared.txt

You resolve it by editing the file to the final, correct content (removing the <<<<, ====, >>>> markers), then git add the resolved file and git commit to complete the merge. The method, not panic, is what they want: open the file, decide the right result, stage, commit. Tools and git mergetool help, but the manual edit is the fundamental skill.

Q12. What is the difference between git reset, git revert, and git restore?

Three different undo tools. git reset moves the current branch pointer to an earlier commit, rewriting history (used for local cleanup). git revert creates a new commit that undoes a previous commit's changes, leaving history intact (used to undo something already shared). git restore discards changes in your working directory or unstages files, without touching commits at all. The rule of thumb: restore for uncommitted changes, reset for local history, revert for shared history. Picking the right one for "undo a pushed commit" (Q29) is a classic test.

Q13. Explain git reset --soft, --mixed, and --hard.

All three move the branch pointer; they differ in what they do to the staging area and working directory. --soft moves HEAD only and leaves your changes staged. --mixed (the default) also unstages the changes, leaving them in your working directory. --hard resets everything and discards the changes entirely. You can see the difference in git status right after:

$ git reset --soft HEAD~1
$ git status -s
M  app.txt          # changes kept, still staged
$ git reset --mixed HEAD~1
$ git status -s
 M app.txt          # changes kept, now unstaged
# --hard would leave a clean tree: the changes are gone

The one to respect is --hard, because it throws away uncommitted work with no prompt. Knowing that --soft keeps everything staged and --hard discards it is the core of the answer, and it leads straight into the reflog question.

Q14. What is git stash and when do you use it?

git stash saves your uncommitted changes onto a stack and reverts your working directory to a clean state, so you can switch context (pull, change branch, fix something urgent) without committing half-done work. You bring it back with git stash pop.

$ git stash
$ git stash list
stash@{0}: WIP on main: 5c2b05d Revert "Important work I will 'lose'"
$ git stash pop

The typical scenario to mention: you are mid-change when an urgent bug needs fixing on another branch, so you stash, switch, fix, switch back, and pop. It is the clean alternative to a throwaway "WIP" commit.

Q15. What is the difference between a branch and a tag?

A branch is a movable pointer to a commit that advances as you commit, used for ongoing lines of work. A tag is a fixed pointer to a specific commit that does not move, used to mark a point in history, usually a release like v1.2.0. The mental model: branches move, tags stand still. Annotated tags also store metadata (tagger, date, message), which is why releases use them.

Q16. What is a remote, and what do origin and upstream mean?

A remote is a named reference to another copy of the repository, usually hosted somewhere like GitHub. origin is the conventional name for the remote you cloned from. upstream is the convention, in a fork-based workflow, for the original repository you forked, so you can pull in its updates while pushing your own work to origin. They are just names, but knowing the fork convention (origin is yours, upstream is the source) signals you have worked with open-source or team forks.

Q17. How do you undo the last commit?

It depends on whether you pushed it. If it is local and you want to keep the changes, git reset --soft HEAD~1 moves the commit away but keeps your work staged. If it is local and you want it gone entirely, git reset --hard HEAD~1. If it is already pushed and shared, do not reset, use git revert HEAD to add a new commit that undoes it without rewriting shared history. The "pushed or not" distinction is the whole point of the question, so always ask or state it.

Advanced

Q18. What is interactive rebase, and how do you squash commits?

git rebase -i lets you rewrite a series of commits before sharing them: reorder them, edit messages, drop them, or squash several into one. You run git rebase -i HEAD~3, then in the editor mark commits as squash (or fixup) to fold them into the one above. The use case to give: cleaning up a feature branch that has ten "wip" and "fix typo" commits into one or two meaningful commits before opening a pull request, so reviewers see intent, not noise. Since it rewrites history, you only do it on commits you have not shared.

Q19. What is git cherry-pick and when is it useful?

git cherry-pick <commit> applies the changes from a specific commit onto your current branch, creating a new commit with the same content. It is useful when you want one particular commit but not the whole branch, the classic case being a hotfix made on one branch that you need to bring into a release branch without merging everything else. The caution worth adding: cherry-picking duplicates the change as a new commit, so overusing it across long-lived branches can create confusing history.

Q20. What is the reflog, and how does it save you?

The reflog records every move your HEAD makes (commits, resets, checkouts, rebases), even ones that are no longer reachable from any branch. That is what makes it the safety net for "I lost commits". After a reset --hard that drops a commit, the reflog still has it:

$ git reset --hard HEAD~1
$ git reflog
7ab0991 HEAD@{0}: reset: moving to HEAD~1
3b827c7 HEAD@{1}: commit: Important work I will 'lose'
7ab0991 HEAD@{2}: commit (merge): Merge feature, resolve conflict
$ git reset --hard 3b827c7    # back to the "lost" commit

The commit was never really gone; it was just unreferenced. Knowing the reflog exists turns a panic ("I destroyed my work") into a thirty-second recovery, which is exactly the calm interviewers want to see. It is local and time-limited (entries expire after weeks), but for recent mistakes it almost always saves you.

Q21. What is a detached HEAD state?

Normally HEAD points to a branch, which points to a commit. A detached HEAD means HEAD points directly at a commit instead of a branch, which happens when you git checkout <commit-hash> or a tag. You can look around and even commit, but those commits do not belong to any branch, so they are easy to lose when you switch away. The fix if you made commits you want to keep: create a branch there with git switch -c <name> before leaving. Recognizing detached HEAD and knowing how to keep work made in it is the answer.

Q22. To undo a commit that is already pushed and shared, do you use reset or revert?

git revert, almost always. Reset rewrites history, so resetting a shared branch and force-pushing breaks everyone else's history and is how teams lose work. git revert instead adds a new commit that undoes the target commit's changes, which is safe because it does not alter existing history, just appends to it.

$ git revert --no-edit HEAD
$ git log --oneline
5c2b05d Revert "Important work I will 'lose'"
3b827c7 Important work I will 'lose'

Both the original and the revert stay in history, which is honest and safe on a shared branch. "Reset for local, revert for shared" is the principle they are listening for.

Q23. How does Git store data internally?

Git is a content-addressable store of objects. There are blobs (file contents), trees (directories, mapping names to blobs and other trees), and commits (a tree snapshot plus parent, author, and message), each addressed by the SHA hash of its content. Because objects are keyed by content hash, identical content is stored once, and any change produces a new hash all the way up to a new commit. You do not need this daily, but understanding that branches and tags are just lightweight pointers to commit objects explains why branching is so cheap and why history is tamper-evident.

Q24. What is git bisect?

git bisect is a binary search through your history to find the commit that introduced a bug. You mark a known-good commit and a known-bad one, and Git checks out the midpoint for you to test; you tell it good or bad, and it halves the range each time until it pinpoints the offending commit. The value is speed: finding the bad commit among a thousand takes about ten steps instead of a linear hunt. Mentioning that it can be automated with a test script (git bisect run) is a strong bonus.

Scenario and Troubleshooting

These questions mirror real mistakes, not trivia, and the best preparation is having actually recovered from one. KodeKloud Engineer hands you exactly this kind of real Git ticket on a live system, so you can walk in having already untangled the mess they are asking about.

Q25. You committed to the wrong branch. How do you move the commit?

If you have not pushed, the clean fix is to move the commit to the right branch and remove it from the wrong one. Create or switch to the correct branch (git switch -c right-branch brings the commit if it is the latest), or cherry-pick the commit onto the right branch and then git reset --hard HEAD~1 on the wrong branch to drop it. The key is order: get the commit safely onto the correct branch first, then remove it from the wrong one. If you have already pushed the wrong branch, prefer revert over history rewriting.

Q26. You accidentally committed a password. How do you remove it?

The hard truth first: deleting it in a new commit is not enough, because it still lives in history and anyone with the repo can find it. So the real answer has two parts. First, rotate the secret immediately, treat it as compromised, because it is. Second, scrub it from history with git filter-repo (or the BFG tool) and force-push, then have everyone re-clone. The order matters: rotate first, because rewriting history does not help if someone already pulled the secret. A candidate who says "rotate it, assume it leaked" before reaching for the history rewrite is thinking about security correctly.

Q27. You ran git reset --hard and lost commits. How do you get them back?

Stay calm and reach for the reflog (Q20). git reflog lists where HEAD has been, including the commit you just dropped, and you recover it with git reset --hard <that-sha> or by creating a branch at it.

$ git reflog
3b827c7 HEAD@{1}: commit: Important work I will 'lose'
$ git reset --hard 3b827c7

The commit was unreferenced, not deleted, so as long as it has not been garbage-collected (weeks, normally) it is recoverable. The fact that you know this, instead of assuming the work is gone, is the entire point of the question.

Q28. A git pull stopped with a merge conflict. Walk me through it.

A pull is a fetch plus a merge, and the merge hit conflicting changes. Run git status to see which files conflict, open each one and resolve the <<<</====/>>>> markers to the correct final content, then git add each resolved file and git commit to finish the merge (or git rebase --continue if your pull was configured to rebase). If it goes badly and you want to start over, git merge --abort returns you to the pre-pull state. The structure is the same as Q11: see what conflicts, decide the right content, stage, commit.

Q29. How do you undo a commit that is already pushed and shared with the team?

git revert, not reset. On a shared branch, rewriting history and force-pushing would clobber everyone else's work, so you add a new commit that reverses the bad one with git revert <commit>. History stays intact, the bad change is neutralized, and your teammates just pull the revert normally. This is the same principle as Q22, and it is one of the most common real-world Git questions because getting it wrong on a shared branch causes actual damage.

Q30. Your feature branch has fifteen messy commits and is behind main. How do you clean it up before the PR?

Two moves, both before you share. First, interactive rebase (git rebase -i main) to squash the "wip" and "fix typo" commits into a few meaningful ones with clear messages. Second, that same rebase replays your work on top of the current main, so your branch is up to date and the eventual merge is clean, often a fast-forward. The reviewer then sees a tidy, logical series of commits instead of your thinking-out-loud history. The caveat to state: this rewrites your branch's history, which is fine because it is your unshared branch, but you would not do it to main.

Quick-Revision Cheat Sheet

The night before, scan this instead of rereading the guide.

Conclusion

Across every question here, two ideas keep returning: a change moves through three areas, and a commit is an immutable snapshot that branches simply point at. Reset, revert, stash, reflog, merge, rebase all make sense once you hold those two pictures in your head. Memorize commands and the follow-up question will catch you; understand the model and the commands explain themselves.

In the last 48 hours before an interview, do not re-read all thirty answers. Make a throwaway repo and actually do the scary things: trigger a merge conflict and resolve it, reset --hard a commit and recover it from the reflog, squash a few commits with interactive rebase. The calm you want in the room comes from having already done the thing once. KodeKloud's GIT for Beginners course is project-based with hands-on labs for exactly that, and this KodeKloud explainer is a quick refresher on the fundamentals:

Ready to Practice on a Real Repository?

Reading Git answers is one thing. Resolving a real merge conflict, recovering a commit from the reflog, and squashing a messy branch with interactive rebase are different skills, and they only come from doing them. The GIT for Beginners course on KodeKloud is project-based, you work as part of a team with hands-on labs after each concept, so these commands become reflexes instead of flashcards. If you are also being asked about GitHub specifically, the GitHub Foundations course maps to the certification.

Create your free KodeKloud account ->

FAQs

Sources: Git for Beginners; How Git Works; Git vs GitHub vs GitLab; Unraveling the 6 Most Confusing Git Commands; GIT for Beginners course. All commands run on git 2.52.0.