The Git Question That Ninety Percent of Candidates Fumble

Interview Insights · Git

The Git Question That Ninety Percent of Candidates Fumble

SECTION 01Why such a simple Git question trips people up

Most freshers learn Git alone. They create a repository, push to their own GitHub, and nobody else ever pulls from it. In that world, rewriting history costs nothing, so git reset --hard followed by git push --force feels like the natural undo button. Tutorials often show it that way too.

In a company, the main branch is shared by many developers and usually by a CI pipeline. If you rewrite a commit that others have already pulled, their local branches no longer match the remote. The next time they pull, they get confusing conflicts or, worse, they push your bad commit back. So when I ask this question, I am really testing one thing: do you think about the team before you type?

Interviewer: You pushed a commit to main that broke the build.
How do you undo it?

Candidate: I will do git reset --hard HEAD~1
and then git push -f.

Interviewer: Three other developers already pulled main.
What happens to them?

Candidate: ... they can also reset?

Interviewer: You pushed a commit to main that broke the build.
How do you undo it?

Candidate: Since it is already on main, I assume others
may have pulled it, so I will not rewrite history.

  git log --oneline -5        # find the bad commit
  git revert a1b2c3d          # creates an undo commit
  git push origin main

If the commit had never been pushed, I would use
git reset instead, because then nobody else is affected.

Notice that the strong candidate asks the important question before choosing a command. That habit matters more to me than knowing every flag.

SECTION 02Reset and revert: what each one actually changes

To answer confidently, you need a mental model, not a memorised line. Git has three places your work lives: the working directory (files on disk), the staging area or index (what will go into the next commit), and the commit history (what HEAD and the branch point to).

git reset moves the branch pointer backwards, and depending on the mode it also resets the index and the working directory. git revert never moves the pointer back. It reads the bad commit, computes the opposite change, and records that as a brand new commit. That is why revert is safe on shared branches: it only adds history, it never removes it.

# Practise in a throwaway repo
git init reset-lab && cd reset-lab
echo "v1" > app.txt && git add . && git commit -m "v1"
echo "v2" > app.txt && git commit -am "v2"

git reset --soft HEAD~1
git status            # app.txt is staged with v2

git commit -m "v2 again"
git reset --mixed HEAD~1
git status            # app.txt modified, not staged

git commit -am "v2 once more"
git reset --hard HEAD~1
cat app.txt           # v1, the v2 change is gone

# Continue in the same repo
echo "v2" > app.txt && git commit -am "v2"
echo "bug" >> app.txt && git commit -am "add bug"

git log --oneline
# 3f9e1c2 add bug
# 7a1d4b0 v2
# ...

git revert --no-edit HEAD
git log --oneline
# 9c0a7e5 Revert "add bug"
# 3f9e1c2 add bug
# 7a1d4b0 v2

cat app.txt           # v2, bug line removed, history kept

If the bad commit is a merge commit, revert needs to know which parent is the main line. That is what git revert -m 1 MERGE_SHA does. Mentioning this as a follow-up shows real experience, but do not lead with it.

SECTION 03When things already went wrong: reflog and safer force pushes

A good follow-up question from me is: 'Suppose you already ran git reset --hard by mistake and lost a commit. Can you get it back?' Many candidates say no. The answer is usually yes, because Git keeps a local log of where HEAD has pointed, called the reflog. Commits that no branch points to are not deleted straight away, so you can find their SHA and restore them.

The second follow-up is about force pushing. Sometimes rewriting history is correct, for example cleaning up your own feature branch before a pull request. In that case, git push --force-with-lease is the safer form. It refuses to overwrite the remote if someone else pushed in the meantime.

git reset --hard HEAD~1     # oops, lost a good commit

git reflog
# 7a1d4b0 HEAD@{0}: reset: moving to HEAD~1
# 3f9e1c2 HEAD@{1}: commit: add login validation
# 7a1d4b0 HEAD@{2}: commit: v2

git reset --hard 3f9e1c2    # back to the lost commit
# or keep it on a new branch instead:
git branch rescue 3f9e1c2

# Cleaning up your own feature branch before a PR
git checkout feature/login
git rebase -i main          # squash fixup commits

# Unsafe: overwrites the remote no matter what
# git push --force

# Safer: fails if the remote moved since your last fetch
git push --force-with-lease origin feature/login

# Never do this on main or any shared release branch.

Note that git rebase -i opens an editor, so in an interview you can simply describe it: 'I would squash my small fixup commits interactively, then push with force-with-lease because it is my branch.'

SECTION 04Practice lab: make the undo answer automatic

Reading about reset and revert is not enough. You need to break a repository on purpose and fix it a few times, so that the right answer comes out calmly under pressure. Use these three exercises in a throwaway folder, never in a real project.

SIMULATE A TEAM ON ONE LAPTOP

1. git init --bare team.git
2. git clone team.git alice
3. git clone team.git bob
4. In alice: commit and push two commits.
5. In bob: git pull.
6. In alice: git reset --hard HEAD~1 and push --force.
7. In bob: make a commit and try git pull.
   Observe the confusion.
8. Repeat, but in step 6 use git revert instead.
   Observe that bob pulls cleanly.

Write one line about what you saw each time.

LOSE AND RECOVER A COMMIT

1. Make three commits in a test repo.
2. Run git reset --hard HEAD~2.
3. Without looking at notes, run git reflog.
4. Find the SHA of the newest lost commit.
5. Create a branch at it: git branch rescue SHA
6. Check: git log rescue --oneline

Time yourself. Repeat until it takes
under one minute without notes.

60-SECOND SPOKEN ANSWER

Practise saying this structure out loud:

[ ] Ask: has it been pushed and pulled by others?
[ ] If shared: git revert SHA, then push
[ ] If local only: git reset (soft, mixed or hard)
[ ] Mention reflog for accidental resets
[ ] Mention --force-with-lease for own branches
[ ] Mention branch protection on main

Record it on your phone. Remove filler words.
Stop when all six boxes are covered.

SECTION 05Habits that make Git questions feel easy

These habits help you answer the undo question and its many cousins without guessing.

• Ask about the branch first — Before naming any command, ask or state whether the work is local, on your own branch, or on a shared branch. That one question shapes the whole answer.
• Run git status constantly — Candidates who read git status output aloud during live tasks look calm, because they always know what state the repository is in.
• Keep a scratch repo — Have a small test repository where you can try any command safely. Experimenting there builds the mental model faster than any video.
• Learn what each command moves — For every command, know whether it changes the branch pointer, the staging area or the working files. Most Git confusion comes from mixing these up.
• Prefer adding over deleting — On shared history, a new commit that fixes things is almost always safer than removing old commits. Say this principle in your answer.

SECTION 06Interview Q&A — Undoing a pushed commit

SECTION 07Test yourself — Undoing a pushed commit quiz

SECTION 08Frequently asked questions

SECTION 09Related reads