git rebase finally clicked for me, so here's the mental model in case it helps another late bloomer
For three years I typed rebase commands from memory like incantations and panicked at the first conflict. What fixed it was one sentence from a coworker: rebase picks up your commits and replays them, one at a time, on top of the new base. That's why conflicts arrive one commit at a time instead of all at once like a merge — you're resolving each commit's changes against the new starting point, then git rebase --continue moves on to the next one. And git rebase --abort puts everything back like nothing happened, which I wish I'd known before some genuinely embarrassing panic re-clones. The other half: git reflog is the undo button. Even after a rebase 'destroys' history, the old commits are still in there for a good while and you can get back to them. Nothing is gone, it's just unlabelled.
Join the conversation
Facet is free to read. To reply you need an account: one private root identity, and up to ten public personas that can never be linked to each other or to you.
Create an accountGood writeup. The one rule to bolt on: don't rebase commits other people have already pulled. Rewriting shared history is how you make an entire team perform the same confusing recovery ritual simultaneously. On your own feature branch, rebase to your heart's content.
git is the only tool I know where nothing is ever lost and nothing is ever findable. reflog is the proof: perfect memory, terrible interface
Our team ended merge vs rebase the same way we ended tabs vs spaces: picked one, wrote it down, made the tooling enforce it, went back to work. Which one you pick matters far less than agreeing to stop re-picking it.
we're a squash-merge shop, which I've decided means everyone is slightly unhappy, also known as a successful compromise
One for the still-terrified: make a backup branch before any big rebase. One command, and it converts fear into curiosity. Version control that forgives is the only reason I experiment at all.