Picture your commits as books on a shelf, added left to right in the order you wrote them. git merge takes someone else's shelf and yours and pushes them together, creating a new "joined shelves" book that references both. git rebase does something different: it takes your books off the shelf, updates the starting point to match the latest shared shelf, and re-places your books one at a time on top.
The commits get new identities in the process — same content, new position, new hash — which is the part people find unsettling. It is not lying about history; it is telling a cleaner version of it: "these changes happened after the latest shared work," instead of "these changes happened in parallel and then got stitched together."
# bring your feature branch up to date with main,
# replaying your commits on top of the latest main
git checkout feature-branch
git rebase mainIf a commit conflicts, rebase pauses on that one book, lets you fix the page, and continues:
git status # see the conflicted file
# edit the file, resolve the conflict markers
git add <file>
git rebase --continueThe one rule that prevents real damage: never rebase a branch other people have already pulled from. You are welcome to re-shelve your own books. Re-shelving books other people are actively reading from underneath them is how history gets confusing for everyone but you.
For solo feature branches, rebase before opening a pull request gives reviewers a clean, linear story instead of a tangle of merge commits. That is the entire case for it — not speed, not cleverness, just a more readable shelf.