As melhores formas de escrever mensagens de commit Git: Tal como os profissionais

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:

1. Commits Convencionais
2. Commits Semânticos
3. Como escrever uma mensagem de commit por CBeams

\