alt Hacker NewsAfter more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walking a tightrope where screwing up was painful and expensive, and easy to take the wrong path, and abort is the universal solvent to all of that.
I do still find myself tripping up on whether the next appropriate step is to make a commit or continue the rebase, as that is dependent on if you're in a merge conflict or just editing a commit. But even when I get that wrong, and collapse two commits together, abort saves the day.
Replies
You don't need to keep their hashes because git keeps them for you. If you realise too late that things went terribly wrong, you can get the pre-rebase hashes with "git reflog". (It can take a little getting used to knowing how to identify them quickly after a rebase but they're there.)
> as long as I keep their hashes
that means my hashes or their hashes or them keeping my hashes, I am never sure
This is a perfect use for tags. They allocate no extra storage space, and act as "savepoints" which you can refer to at any time. (Branches move, tags stay put.) They also guarantee that those loose ends are not garbage collected. Sometimes I delete a bunch of old ones, but any codebase of mine will at any time have a handful of old and probably useless tags. But that's ok.