Came here to post this. The key thing to know about git is to always, always, always commit your changes before doing anything that affects history. This is not for data loss reasons, it's for being able to document what is happening; when you have a bunch of unsaved work, you don't know what's there and git doesn't know what's there. Therefore, it's very easy to get yourself into a state where you don't "care" about your working copy, and that's when you can do something where you lose work. If you commit before you do any merging or pulling every single operation that you perform afterwards can be reverted cleanly. And, you'll have a human readable note that documents what you were thinking at the time.
If you don't put your work into git, it can't track it for you. You can always uncommit if you don't like what you committed. In fact, you should consider your local history to be a work in progress; just like you're editing your source code to keep it clean, you should be editing your history to keep it clean. Git never deletes history, so even if you edit it, you can always get back to where you were. What you call "master" may have changed, but what was master before your rebase still exists, in its entirety, inside of git. (It's simply called HEAD@{0} instead of master. See "git reflog".)
You are correct, though I'd also point out "git stash" which does a quick no-fuss commit and is meant for situations just like this. "git stash" "git pull" "git stash pop" may not be exactly what you said but it should be enough to prevent what happened to this guy and I'd even guess it is what most new git users expect to happen when you do a plain "git pull".
If you don't put your work into git, it can't track it for you. You can always uncommit if you don't like what you committed. In fact, you should consider your local history to be a work in progress; just like you're editing your source code to keep it clean, you should be editing your history to keep it clean. Git never deletes history, so even if you edit it, you can always get back to where you were. What you call "master" may have changed, but what was master before your rebase still exists, in its entirety, inside of git. (It's simply called HEAD@{0} instead of master. See "git reflog".)