Merge vs rebase — what's the difference and when do you use each?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
Merge preserves history as-is with a merge commit showing integration points. Rebase replays your commits onto another base, producing a linear, cleaner history but rewriting commit SHAs. Merge for shared/public branches; rebase for local/private work before sharing.
Detailed explanation
Both integrate changes; they differ in the history they create. git merge main into your branch adds one commit joining both lines — honest about parallel development, easy to revert as a unit, but log graphs tangle over time. git rebase main lifts your commits off their old base and replays them on top: linear readable history, every feature reading as if written against latest main. The cost is rewriting: rebased commits get new SHAs, so teammates who already pulled them face conflicts and confusion — hence the golden rule: never rebase commits others may have based work on (shared branches). Practical workflow: rebase your feature branch onto main locally to stay current and squash messy WIP commits (interactive rebase), merge via PR when done. Teams codify this in policy — 'rebase local, merge remote'. Conflict handling differs too: rebase resolves per-commit (potentially repeatedly), merge once.
Example
# Keep feature current with linear history:
git checkout feature/login
git fetch origin
git rebase origin/main
# Resolve conflicts per commit, then:
git rebase --continue
# Integrate officially (preserves both histories):
git checkout main && git merge --no-ff feature/loginInterview tip
Lead with the SHA-rewriting insight — it explains every team rule. Then give the policy one-liner: rebase private work, merge shared branches.
Common mistakes
- Saying rebase is just 'cleaner' without mentioning rewritten history dangers.
- Not knowing conflicts resolve per-commit during rebase.