Respostas:
As ferramentas de controle de versão são poderosas o suficiente para permitir que a pessoa veja quais arquivos foram modificados e quais métodos foram adicionados. Isso significa que, em geral, as mensagens de log que duplicam claramente o que já existe estão poluindo o log.
Você adicionou um somefuncmétodo para atender a um requisito, ou seja:
Isso significa que suas mensagens de log devem explicar quais recursos / bugs foram afetados ou qual foi o objetivo da refatoração.
Não se esqueça de adicionar o número do bilhete / problema .
Se você tiver algum recurso ou sistema de rastreamento de problemas com um número de ticket ou número de problema , certifique-se de colocar esse número de ID no commit. Isso ajudará quem quiser saber mais sobre o recurso ou problema em que você estava trabalhando.
No meu último projeto, houve uma macro que foi desenvolvida para garantir que os 7 primeiros dígitos do comentário fossem um número de problema válido de uma busca clara (nosso sistema de rastreamento de problemas / recursos).
Eu faço esse tipo de coisa ao confirmar, por exemplo, a correção de um defeito que exigia alterações em vários arquivos. Isso torna um pouco mais fácil dizer o que realmente mudou sem examinar os arquivos individuais no conjunto de alterações.
Para conjuntos de alterações de arquivo único, isso é desnecessário.
A primeira linha é sempre uma descrição de alto nível do changeset, como um link para o defeito ou a história do usuário.
Se houver informações relevantes na narrativa da mensagem de confirmação, inclua-as. Se a única informação é o nome do arquivo, então não.
Por exemplo, isso faz sentido: "Movemos a função build_foo () de fooutil.c para foobase.c, pois a maioria dos programas que deseja usar o build_foo () já inclui o foobase.c"
Este não: "Atualizado o build_foo () no fooutil.c para obter um parâmetro de barra."
Eu quero adicionar uma perspectiva diferente aqui.
Minha resposta é sim ou não. Mas geralmente eu diria que sim.
O controle de versão é realmente poderoso o suficiente para saber qual arquivo está sendo atualizado. Mas quando fazemos
$ git log
Nós vemos apenas a mensagem de confirmação. É o que a maioria das pessoas faz.
Examinando o próprio log. Ele adiciona contexto adicional a ele. Por exemplo:
readme.md: Fix typo detected by language tool
É melhor que
Fix typo detected by language tool
No entanto, se as alterações gerarem vários arquivos, mencione pelo menos o componente que está sendo editado.
API: Fix reset password not sent email to user
Ao ler, sabemos que o erro que está sendo corrigido está no componente API e provavelmente no diretório API na base de código.
No entanto, poderíamos fazer
$ git show COMMIT_ID --name-only
mas adiciona mais etapas apenas para obter os arquivos.
A única vez em que pude ver isso útil para um único check-in de arquivo é se você fez alterações em uma função usada em muitos locais do arquivo, com o resultado de que o diff está desordenado. Mesmo assim, eu colocaria o número do rastreador de alterações e uma descrição em texto simples da alteração.
Eu acho que a verdadeira questão aqui é quão limitado no escopo são seus commits? Se você esperar para confirmar uma variedade de alterações não relacionadas juntas em uma confirmação, poderá sentir a necessidade de especificar quais arquivos foram alterados para qual finalidade.
No entanto, se você simplesmente fez confirmações mais restritas com mais frequência, uma única confirmação explicaria quais arquivos foram modificados e você poderia simplesmente descrever qual era o objetivo da mensagem.
Mais confirmações, com mais frequência. É assim que você pode evitar ser tão detalhado em suas mensagens.