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.