Rebase

Version Controlintermediate

// Definition

Replaying your branch's commits on top of another branch's latest state, producing a linear history instead of a merge commit. `git rebase main` makes your feature branch look as if you started it from the current `main`. Powerful for a clean history, dangerous if used on shared branches — it rewrites commit hashes.

// Why it matters

Rebase keeps history linear and readable, which makes bisecting and reviewing easier — but the QA-relevant warning is that rebasing shared branches rewrites history others have, breaking their clones. Knowing when rebase is safe (your own unpushed work) vs dangerous (shared branches) prevents a class of team-wide Git disasters.

// How to test

git switch feature/login-tests
git rebase main        # replay my commits on top of latest main → linear history
# ⚠️ NEVER rebase a branch others have pulled — it rewrites hashes
# safe: only rebase your own un-pushed (or solely-yours) commits

// Common mistakes

  • Rebasing a shared/pushed branch others depend on (rewrites their history)
  • Resolving the same conflict repeatedly across many replayed commits without --continue discipline
  • Confusing rebase (rewrites) with merge (preserves) and picking the wrong one

// Related terms