rebase
To rebase is to pick up your branch's commits and replay them, one by one, on top of the latest version of another branch — as if you'd started your work just now instead of last week. The result is a clean, straight line of history with no 'merge' detours in it.
It solves a real annoyance. While you were building your feature, main moved on. A merge would join the two lines and leave a visible fork-and-rejoin in the history; a rebase instead rewrites your commits so they sit neatly on the new tip of main, as though the divergence never happened. Same final code, tidier story.
The one rule to tattoo on your arm: never rebase commits you've already shared. Rebasing rewrites history — it gives your commits brand-new IDs — so doing it to work others have pulled will tangle everyone's copies. Rebase your own private branch before sharing it; merge when the work is already public.
$ git switch fix-login $ git rebase main Successfully rebased and updated refs/heads/fix-login.
Replay your fix-login commits on top of the newest main — straight history, no merge bubble.
Merge vs rebase isn't right vs wrong — merge preserves exactly what happened; rebase tidies it into a straight line. Pick per team taste.