A documentação "oficial"1 do git tem um recomendações sobre commits e mensagens. São um conjunto de boas práticas pra tornar a nevegação pelo hitórico do projeto mais fácil de assimilar.
Apesar de não serem obrigatórias, elas são fartamente aplicadas e replicadas pela internet:
Verifique problemas de whitespace no código
Essa é fácil, só executar git diff --check antes do commit, e qualquer erro de espaçamento extra vai ser listado.
Commits devem ser mudanças pequenas e completas no código
Duas coisas para se ter em mente é que um commit deve sempre funcionar sozinho. Se você implementou uma funcionalidade que levou 20 commits, cada um deles deve adicionar (ou remover) uma parte de maneira completa, e o programa deve continuar totalmente funcional. Isso não significa que os commits devem ser enormes, contendo centenas de linhas alteradas ao longo de dias. Procure fazer mudanças pequenas e incrementais.
Formato da mensagem
Essa é uma parte tão essencial quanto as outras. Um projeto que mantém o mesmo padrão de mensagens é mais fácil de entender e acompanhar. Não faz muito sentido ser a única pessoa do projeto a trabalhar assim... Se você conseguir que todo mundo escreva as mensagens nesse formato, tudo vai ser mais fácil:
Espaçamento de 1 linha entre o título do commit e o resto da mensagem
O título deve ter no máximo 50 caracteres
O título deve começar com letra maiúscula
O título não deve terminar com '.'
O título deve estar no presente da segunda pessoa:
Ao invés de "Eu adicionei testes para" ou "Adicionando testes para", use "Adiciona testes para"
Corpo da mensagem não deve ter largura maior que 72 caracteres
Corpo da mensagem deve explicar o que e por que, não como.
exemplo: http://pt.stackoverflow.com/questions/60729/quais-seriam-as-pr%C3%A1ticas-recomendadas-para-commits-no-git/61431#61431
Acredito que a questão esteja relacionado ao conteúdo clean code. Vejamos o trecho abaixo.
Attributions and Bylines
/* Added by Rick */
Source code control systems are very good at remembering who added what, when.
There is no need to pollute the code with little bylines. You might think that such comments would be useful in order to help others know who to talk to about the code. But the
reality is that they tend to stay around for years and years, getting less and less accurate
and relevant.
Again, the source code control system is a better place for this kind of information.
....
Sometimes people add a comment to the start of a module every time they edit it. These
comments accumulate as a kind of journal, or log, of every change that has ever been
made...Long ago there was a good reason to create and maintain these log entries at the start
of every module. We didn’t have source code control systems that did it for us. Nowadays,
however, these long journals are just more clutter to obfuscate the module. They should be
completely removed.