I didn't know about --word-diff though - I'll be aliasing that to be the default for `git diff` for sure!
If I'm right the point of the tip is just to simplify this set of steps into a one-liner (which would help if you did this rebase and merge often).
In any case, I'm pretty sure that this is separate from squashing all the commits on the feature branch.
* The first command switches over to that feature branch.
* The second command rebases off of master, which basically rewinds the changes on his branch and applies them to the latest version from master - think of this like getting latest and merging in your pending changes.
* The third command switches back to master.
* The fourth command merges the feature branch into master - this should be what is called a "fast-forward merge" and not require a separate merge commit since you rebased your branch.
The rebase is really used to make it a cleaner merge back into master (and a cleaner history in general), not to squash commits in this case (though you also would use rebase to squash, that's another topic).
What I pointed out is that (for me at least) the rebase from master is not usually "clean" - meaning there are merge conflicts that I have to resolve - so chaining together shell commands like this doesn't really help when the second command is going to need intervention from me before I can run the third.
Hope that helps (and I hope my analysis is right or I'll look silly!)