intermediate

Rebase

Replay commits onto a new base to produce linear history while understanding rewritten commit identities.

Rebase replays commits onto a new base, creating **new commit IDs** (new hashes). It rewrites history — useful for cleaning a local feature branch before review, dangerous on shared branches without coordination.

					git switch feature/login
git fetch origin
git rebase origin/main
git rebase -i HEAD~4    # squash, reword, reorder last 4 commits
				

After rebase, pushing to a remote branch that others use typically requires `git push --force-with-lease` — safer than blind `--force` because it refuses if the remote moved unexpectedly.

On interviews: why rebase changes hashes, when interactive rebase is appropriate, and coordination rules for shared branches.

Common pitfalls: rebasing public branches duplicates work; conflict resolution during rebase needs care at each replayed commit; confusing rebase with merge policy on pull.

The trade-off is linear, review-friendly history versus the safety of non-rewritten shared refs.

Checklist:

  • Use rebase for local cleanup before PR.
  • Avoid rewriting history others already built on.
  • Prefer `--force-with-lease` when push rewriting is required.
  • Document team policy: rebase vs merge on PR integration.