Uma mensagem de commit do git deve mencionar o arquivo que foi modificado?

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 simplesmente duplicam o que já existe estão poluindo o log.

Você adicionou o método somefunc para atender a um requisito, por exemplo:

• para adicionar um recurso,
• para remover um bug ou
• para refatorar o código-fonte.

Isso significa que suas mensagens de log devem explicar quais recursos / bugs foram afetados ou qual foi o propósito da refatoração.

Não. Existem muitas maneiras de examinar os conteúdos de um commit. O comentário deve descrever o propósito do commit.

Não se esqueça de adicionar TICKET / NÚMERO DE PROBLEMA .

Se você tiver algum recurso ou sistema de acompanhamento de problemas com um ticket # ou issue # , coloque esse ID no commit. Isso ajudará qualquer pessoa que queira saber mais sobre o recurso ou problema em que você estava trabalhando.

No meu último projeto, havia uma macro que foi desenvolvida para garantir que os primeiros sete dígitos do comentário fossem um número de problema válido da missão clear (nosso sistema de rastreamento de problemas / recursos).

Eu faço esse tipo de coisa quando estou cometendo, e. 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 olhar para arquivos individuais no changeset.

Para conjuntos de alterações de arquivo único, isso é desnecessário.

A primeira linha é sempre uma descrição de alto nível do conjunto de alterações, como um link para o defeito ou a história do usuário.

Se for uma informação relevante na narrativa da mensagem de confirmação, então sim, inclua-a. Se o único bit de informação é o nome do arquivo, então não.

Por exemplo, isso faz sentido: "Moveu a função build_foo () de fooutil.c para foobase.c, já que a maioria dos programas que querem usar o build_foo () já estão incluindo o foobase.c"

Este não: "Atualizou o build_foo () em fooutil.c para obter um parâmetro de barra."

A única vez que eu vi isso sendo útil para um check-in de um único arquivo é se você fez alterações em uma função usada em muitos lugares dentro do arquivo com o resultado que o diff é desordenado. Mesmo assim, eu colocaria o rastreador de alterações # e uma descrição de texto simples da alteração primeiro.

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 só vemos a mensagem de commit. Isso que a maioria das pessoas faz.

Examinando o próprio log. Acrescenta 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 lê-lo, sabemos que o erro que está sendo corrigido está no componente da API e provavelmente no diretório da API na base de código.

No entanto, podemos fazer

$ git show COMMIT_ID --name-only 

mas adiciona mais etapas apenas para obter os arquivos.

Eu acho que a verdadeira questão aqui é quão limitado no escopo são seus commits? Se você esperar para consolidar uma variedade de mudanças não relacionadas em um commit, talvez seja necessário especificar quais arquivos foram alterados com o objetivo.

No entanto, se você simplesmente tornasse mais restrito o commit com mais frequência, então um único commit explicaria quais arquivos foram modificados e você poderia simplesmente descrever qual era o propósito da mensagem.

Mais commits, com mais frequência. É assim que você pode evitar ser tão detalhado em suas mensagens.

Não deve

Todo mundo que estiver interessado pode ver as alterações em uma história

Também não é viável em sistemas maiores, pois muitos arquivos podem ser gerados automaticamente