Nice explanation. When I was first learning git, the most intuitive explanation of git rebase were these three links (if read in order... these links were once published on Hacker News many moons ago):
(1) http://gitready.com/intermediate/2009/01/31/intro-to-rebase....
(2) http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm...
(3) http://gitready.com/advanced/2009/03/20/reorder-commits-with... <~ talks about "interactive mode" with the -i option
You can also use the same command to squash multiple commits into one. This is useful when you write a commit, then have several commits gradually adding temporary debugging statements and unit tests, then more commits to fix any problems uncovered, then more commits to remove extensive print statements and other temporary debugging code.
Assuming you get the code working, most of these commits will be totally irrelevant to future development efforts. With the "squash" feature of git rebase -i, you can condense all these commits into a single commit containing only working code and unit tests, springing fully formed in a single commit, like Athena from the head of Zeus.
The git rebase -i command will also let you re-word or edit commits; the utility of those functions should be obvious.