For certain changes, a clean branch history can be very valuable during review. For example, if you had some feature which was rolled back due to bugs, a new branch with the feature plus the fixes should have the original (buggy) feature as the first commit(s) with no other modifications so that people can clearly see what was done to fix the original bugs and what was in the original code.
However, you can fix things up when ready for review by just rebasing things into a coherent sequence of commits. I really wish there was a good autocommit/push feature in Git that would help back things up but continuously rebase and compact old autocommits.
It's true. Making a very clean git commit history is key to making the most use of git. That's partly in choosing sizes of commits (does one thing, not two things), partly in choosing good commit messages, and partly in branching strategy.
Personally I try to avoid merges at all costs. Instead, I always try to keep feature branches cleanly rebased off master. This sucks with github, so I have a tendency to destroy and recreate feature branches to avoid getting merge commits mixed up in the remote. GitHub is dumb like that. I don't really know how to fix that except to suggest that some branches on remote should be auto-rebased if it can be done cleanly. But it's still a pain.
However, you can fix things up when ready for review by just rebasing things into a coherent sequence of commits. I really wish there was a good autocommit/push feature in Git that would help back things up but continuously rebase and compact old autocommits.