💼 Git and GitHub Interview Questions

Git and GitHub Interview Questions: Listing Git commands in an interview is like asking a driver to recite road signs from memory: knowing the signs is necessary, but nobody hand

Listing Git commands in an interview is like asking a driver to recite road signs from memory: knowing the signs is necessary, but nobody hands over the keys for that — what they actually want to know is which call you make at a crowded junction. So if you already know what `git revert` and `git reset` do, why isn't saying that enough? Because the real question is not "which one is correct" but "do you see what rewriting history on a shared branch costs your team" — the command is the threshold, the reasoning is the differentiator. Java works the same way: explaining how a `HashMap` works is mid-level, explaining what silently disappears in production when the `equals`/`hashCode` contract is broken is senior-level. In QA terms the competency being measured is clear: you are accountable not only for your own commits but for the team's history, for whether a change can be rolled back, and for whether the origin of a regression can still be proven six months later. So build every answer on three legs: what you did, why you chose that route, and how you get back if it goes wrong.

🎬 The Anatomy of a Strong Scenario Answer

The interviewer asks: "You accidentally committed to main and have not pushed yet — what do you do?" In this film you will watch the difference between two answers to the same question — rote versus structured.

The weak reflex: "I would use git reset." Which reset? Is work lost? What if it had been pushed? Memorizing a command name is equivalent to being able to search Google — the interviewer sees NO depth here.

Layer 1 of the strong answer — CHECK the situation: "First I confirm what was committed and whether it was pushed, with `git status` and `git log --oneline -3`. If there is no push, the history still lives only on my machine — I have room to move."

Layer 2 — command + RATIONALE: "I would run `git reset --soft HEAD~1`, because it undoes the commit while KEEPING the work staged. `--hard` would also undo the commit but would destroy the work." Saying why you did NOT choose the alternative is worth more than the command itself.

Layer 3 — TEAM safety: "HAD the commit been pushed, I would not use reset; rewriting shared history breaks the team's references. There I would add an undo commit with `git revert`." This sentence is the proof of real team experience.

Layer 4 — the Java bridge: "reset --soft is like 'undo commit' in the IDE — the change stays, the record is taken back; revert is a compensating transaction like a reversing entry in accounting: it never erases history, it adds a new correcting record." Bridging to a world you know makes the answer stick.

Final — the formula: situation check → command + rationale → team safety/risk → Java analogy. Run your answer through these 4 layers for every interview question below; the candidate who thinks in order always beats the one who memorized commands.

Step by Step: Building a Scenario Answer

Clarify the situation

Open by clarifying conditions: was it pushed, how many commits, who is affected? The interviewer wants to hear you ask these — it is also the first step in real work.

Name the evidence commands

Say "first I look with `git status` and `git log`" — the point is showing the evidence-gathering reflex, not fearlessly listing commands.