Quando um desenvolvedor volta no tempo para procurar algo em que trabalhou há seis meses, muitas vezes ele não entende por que fez aquele commit específico, e a única razão para isso é porque ele não seguiu a forma correta de escrever a mensagem de commit.
\ Existem padrões de mensagem de commit que os desenvolvedores praticam em todo o mundo, e é bom seguir padrões populares para que quando você voltar depois de um bom tempo ou outra pessoa olhar para suas mensagens de commit, elas não pareçam estranhas!
\
\ As equipas devem primeiro decidir sobre uma convenção de mensagem de commit que especifique o histórico de controlo de versão do produto que estão a construir.
\ Uma boa mensagem de commit do Git deve ter um estilo adequado, conteúdo e metadados.
\ Um commit Git conhecido segue esta convenção:
<type>(<scope>): <message>
\ <type> pode ser um dos seguintes:
feat para uma nova funcionalidade.refactor para refatoração de código de produção, por exemplo, renomear uma função.docs para alterações na documentação.fix para uma correção de bug para o utilizador.perf para melhorias de desempenho.style para alterações de formatação, ponto e vírgula em falta, etc.test para adicionar testes em falta, refatorar testes.build para atualizar a configuração de compilação, ferramentas de desenvolvimento ou outras alterações irrelevantes para o utilizador.\ Também pode adicionar o seu tipo personalizado, dependendo dos padrões que a sua equipa segue. Os padrões acima são seguidos pela equipa ESLint. Pode verificar as suas mensagens de commit aqui.
\ O escopo é opcional, e a parte da mensagem deve incluir uma declaração de linha única, não mais de 72 caracteres, para resumir para que serve o commit.
\ Muitos desenvolvedores também usam a mensagem como linha de assunto e adicionam um corpo também; isso é basicamente a descrição do commit, mas uma mensagem de commit de uma linha é preferível desde que se possa entender o contexto (o quê e porquê do commit). Se o commit exigir uma descrição mais detalhada que não possa ser explicada numa única linha, um corpo de commit é sempre necessário.
\ Também pode usar ferramentas como Glitter ou Commitizen para padronizar as suas mensagens de commit.
\ Não só isso, também pode perguntar-se se existe uma ferramenta que verifica a sua mensagem de commit e mostra um erro se não seguir as diretrizes. Commit lint é uma delas. Ajuda a sua equipa a aderir a uma convenção de commit.
\ Muitas vezes, especialistas da indústria usam o seu ticket JIRA ou Click Up como mensagem de commit para que tudo possa ser vinculado ou rastreado a qualquer momento, e a base de código permanece manutenível para futuros desenvolvedores.
\ Algumas equipas também gostam de adicionar emojis às suas mensagens de commit. Eu organizei uma lista de emojis e seus respectivos significados. Pode verificá-la aqui.
\ No final, o importante é que a sua mensagem de commit seja significativa e não confunda os seus colegas desenvolvedores ou futuros desenvolvedores sobre o que é uma determinada alteração.
\ Se deseja aprender mais sobre commits convencionais, commits semânticos ou as práticas que a indústria segue, aqui estão alguns recursos para si:
\


