Lesson 6 of 30
Merge vs rebase, resolving real conflicts, and the scenario questions interviews actually ask once they're past 'what does git commit do'.
14 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 2
Why is rebasing a branch that other people have already pulled considered dangerous?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
A strong answer covers
Likely follow-ups
A strong answer covers
Likely follow-ups
A strong answer covers
Likely follow-ups
Most interviews don't test whether you know git add. They test what you do when something's gone slightly wrong: a merge conflict, a secret committed by accident, a branch that needs cleaning up before it's shared. The mechanics worth actually understanding:
git merge brings another branch's history into yours, preserving exactly what happened, and adds a merge commit.git rebase replays your commits on top of another branch's latest state — producing a clean, linear history, but by creating entirely new commits with new hashes.Two branches both edited the same line of config.js since diverging from main. Git can't guess which change should win, so it stops and marks the conflict:
<<<<<<< HEAD
const timeout = 3000;
=======
const timeout = 5000;
>>>>>>> feature/longer-timeout
This isn't Git being broken — it's Git correctly refusing to silently pick a winner. You edit the file down to the intended result, remove the markers, then git add config.js and complete the merge with a commit.
main always stays deployable. Every change starts on its own branch: feature/add-checkout.
git fetch and git pull aren't the same. fetch downloads new commits from the remote without touching your current branch at all. pull is fetch + an automatic merge (or rebase, depending on config) into your branch right away.git reset and git revert solve the same kind of problem differently. reset moves your branch pointer and can discard commits — safe on your own unpublished work, dangerous on anything shared. revert creates a new commit that undoes a previous one, leaving history intact — the safe choice once a branch is shared.git stash is for uncommitted work you're not ready to commit yet. It shelves your working-directory changes so you can switch branches cleanly, then reapplies them later with git stash pop.Past the basics, Git questions are almost always scenario-based: "you did X, now what?" They're testing whether you understand what each command actually does to history and remote state — not whether you've memorized a list of commands — because that's what determines whether your fix helps or makes things worse for the rest of the team.