You're not looking at the possibility that someone may do a bunch of development locally, then use rebase to clean it (the local changes) up before pushing it out to a central repository (or merging it into master). If you're really paranoid that someone will use rebase to screw up master, you can use a tool like gitosis or gitolite to manage permissions on a central repository. You can say that no one has permissions to push things to master that are not fast-forwards.

Scenario #1:

  I'm working on a feature branch. I have a number of discrete changes
  that I'm making. I attempt to keep each of these changes in its own
  separate commit. After completing 10 such changes, I realize that I
  introduced a bug in change 3. I commit the bugfix with the same
  commit message title as change 3, but with a "squash!" prefixed at
  the front of it. Now when I'm finished with my changes on the
  feature branch I can run "git rebase -i". git-rebase will
  automatically position the bugfix to change 3 next to change 3 and
  set it up to be squashed into the change 3 commit. Then when I merge
  my changes into master there are only commits for changes 1-12,
  instead of 50 commits covering all of the minor bugs that I fixed
  with my undeployed code.

Scenario #2:

  Rewriting commit messages. This is one that I use all of the time at
  work. I use a commit message template that has "Reviewed-by: ???" at
  the bottom. When I do all of be topic branch development, I don't
  get someone to review each individual commit prior to commiting it
  (as that would defeat the purpose of a DVCS... might as well go back
  to SVN at that point and managing chunks of changes prior to commits
  with something like `quilt`). So now all of my commit messages have
  "Reviewed-by: ???" on them. Prior to merging the changes back into
  master, I can use git-rebase or git-filter-branch to go back and
  edit my history to change "Reviewed-by: ???" to "Reviewed-by: Bob"
  on my commit messages.