Git Interview Questions: Real Practice Quiz

git reset --soft moves the branch pointer (HEAD) back to the target commit but leaves the index and working directory untouched, so everything those 3 commits changed is now staged and ready to re-commit. --mixed (the default) also moves HEAD but resets the index too, so the changes end up unstaged instead. --hard resets the working directory as well, discarding the changes entirely. git revert doesn't rewrite history at all — it adds new commits that undo the old ones, which is the right tool for undoing already-pushed commits, not for restaging local ones.

True. git fetch downloads new commits and refs from the remote without touching your working branch; git pull does that fetch and then immediately integrates the result into your current branch — by default with a merge, or with a rebase if pull.rebase is configured (or git pull --rebase is passed). Understanding pull as these two separate steps is what makes it clear why a pull can produce a merge commit, and why git fetch alone is the safer way to inspect incoming changes before deciding how to integrate them.

Cherry-pick replays exactly one commit's diff, so it's the precise, surgical alternative to a full merge when you only want a single change to travel between branches.

Merging leaves every existing commit's hash untouched and just adds a new merge commit joining the two histories, so teammates' local clones stay valid — their next git pull just fetches the merge commit. Rebasing rewrites feature's commits onto a new base, giving them new hashes; force-pushing that means every commit your teammates already have diverged from the shared history is now based on commits that no longer exist upstream, which turns their next pull into a confusing pile of duplicate/phantom conflicts. This is git's 'golden rule of rebasing': rebase freely on commits only you have, never on commits others have already pulled and built on.

Rebase, commit --amend, and a hard-reset-plus-force-push all replace existing commits with different ones under new hashes — exactly what a force-push overwrites the shared history with, breaking anyone who already based work on the old commits. Merge and revert are both additive: merge creates a new commit that references the existing history without changing any of it, and revert creates a new commit whose diff undoes an earlier one, leaving the original commit (and its hash) exactly as it was. That's why merge and revert are the safe defaults for undoing or integrating already-shared history, while rebase/amend/force-push are reserved for commits nobody else has pulled yet.

When git can't auto-merge a conflicting region, it writes both versions into the file surrounded by <<<<<<<, =======, and >>>>>>> markers and leaves it to the human to edit the file down to the intended result before staging and committing. Here the conflict was never actually resolved — the markers themselves got committed verbatim, which is invalid syntax in any language. The fix is to open the file, decide which value (or a combination) is correct, delete all three marker lines along with whichever side is unwanted, then git add the cleaned-up file and commit. This is one of the most common real-world git mistakes: git commit doesn't validate that conflict markers are gone, so a rushed resolution ships broken code straight into CI.

The core distinction is additive vs rewriting: merge adds a new commit and touches nothing that came before it; rebase replays commits onto a new base, which changes their hashes. That single fact drives the workplace rule — rebase is for cleaning up commits only you have (before a PR, or to keep a personal branch current with main), merge is for anything already shared, because rewriting history teammates have pulled leaves their local repos out of sync with the remote's new hashes.

A merge conflict is git's way of saying it couldn't automatically reconcile two changes to the same region of a file, so it pauses mid-merge and leaves both versions in the file for you to decide between. The flow is always the same: find the marker blocks, edit each file down to what it should actually say (deleting the markers themselves, not just picking a side), stage the resolved files with git add so git knows the conflict is settled, then commit to complete the merge. Skipping the edit step and committing the raw markers is a classic mistake — see the related find-the-bug question.

The gap between what stash saves and what people assume it saves is a reliable source of confusion, because the failure is silent: you stash, switch branch, and your new files are simply there, on the wrong branch, looking like you created them by mistake. Plain git stash takes modifications to tracked files; -u (--include-untracked) adds untracked files and cleans them out of the working directory; -a (--all) goes further and includes ignored files too. Two neighbouring surprises are worth holding at the same time. git stash pop restores everything as unstaged, flattening the staged/unstaged split you had before — --index is what preserves it. And pop only drops the stash entry if applying it succeeded, so a conflicting pop leaves the entry in the list and needs a manual git stash drop once you have sorted the conflict out.

Shallow and partial clone solve the same problem — do not download the whole repository — by cutting along different axes, and the difference decides whether CI still works. --depth 1 truncates history: you get one commit with its ancestry grafted off, so every command that needs to walk backwards has nothing to walk. That is why describe (which counts commits since the nearest tag) and merge-base (which finds a common ancestor) both fail, and why blame in a shallow clone attributes every line to the single grafted commit. --filter=blob:none truncates file contents instead: the full commit and tree graph comes down, blobs are fetched lazily when something actually reads a file, so history-walking commands behave normally. The correction that matters for CI defaults is that --depth also implies --single-branch, so deepening later still leaves you on one branch until you fix the refspec as well. Recovering from a shallow clone is done with git fetch --unshallow, not with gc — garbage collection cannot invent commits that were never downloaded. Tags are a red herring in both directions: a --depth 1 clone does not bring them down at all, and fetching them afterwards still does not help — git fetch --tags retrieves the refs and git describe --tags continues to fail with "No tags can describe", because there is no ancestry between HEAD and the tag left to count. Only git fetch --unshallow restores it.