One thing that drives me crazy is a messy git log full of unimportant commits. While I subscribe to the commit often philosophy during development, it does lead to commits which have no historical significance to upstream project branches. Who needs a git history full of commit messages like
corrected spelling and
fixed a php notice. These commits are helpful during active development, but they just clutter up git history if pushed to an upstream repository. It doesn't have to be this way!
My standard operating procedure is to commit often during development and to use the git interactive rebase tool to squash historically insignificant commits and create one commit with a comprehensive commit message.
While I normally squash to one commit, there is no set rule to do so. I may choose to keep a number of commits if I consider them important to the history of me work. The idea is to push the minimum number of important git commits with well formed commit messages upstream.
Using the git interactive rebase tool to squash commits is a technique, which can be used to remove unnecessary commits, allowing other developers to benefit from an easy to read git history.