I prefer to think of rebase as accomplishing one simply-described task:

Taking a series of commits from anywhere in the repo and replaying it starting from any point in the repo, possibly with modifications.

All the use cases described in the article and crazy CLI options fall out of this simple description. I realize there's quite a bit you need to grok before this becomes obvious, but nevertheless I think it's a good mantra to have as you are learning git and run into problems.

Eventually your mental model shifts from "what does this command option do?" to "what final state of the repository do I want?", and from there it's just a matter of practice.

About that git "eating" commits - they're always recoverable from reflog: see `git log -g`. (where always == until you gc, or delete old clone, or ...)

Otherwise git's interface sucks and is inconsistent, but we're probably past the point of no return. There's always Easy Git and similar projects which aim to make it a bit better if someone wants to use them.

"CAUTION: several people I know, including guys very proficient in Git, have complained about "git ate two days worth of my work!". It is easy to make errors in rebasing and reset --hard, and you may end up losing commits."

Like everything else in git, the solution to this problem is just to make more branches.

If you're about to do something like a rebase, just fork off a new branch first. It makes it trivially easy to get back where you started if something goes wrong. That's the whole point of version control, after all.