Commits convencionais não irão salvar as tuas mensagens de commit

Uma pesquisa rápida na internet irá revelar uma infinidade de artigos que ensinam a escrever mensagens de commit. 90% desses artigos dizem-te para usares commits convencionais. No entanto, um número considerável de desenvolvedores continua a ter dificuldades com isso. Eles sabem que deveriam seguir estas convenções, mas acham difícil aplicá-las na prática. Sempre que fazem commit de código, agonizam sobre se devem escrever "refatorar" ou "rotina". Já vi até projetos onde a lista de mensagens de commit consistia inteiramente na mesma mensagem: "feat: adicionar página", porque escrever mensagens de commit era um desafio muito grande para eles, e eles simplesmente desistiram.

É muito cedo para falar sobre commits convencionais#

Não estou a dizer que commits convencionais são maus. Eles têm muitos benefícios conhecidos:

• Eles proporcionam um formato unificado, tornando as mensagens de commit mais padronizadas
• Eles são fáceis de analisar por ferramentas automatizadas, possibilitando a geração automática de changelogs
• Eles ajudam os membros da equipa a entender o propósito e o âmbito das alterações de código
• Eles permitem identificação rápida dos diferentes tipos de alterações de código

No entanto, quando um desenvolvedor ainda está com dificuldades para escrever boas mensagens de commit, mesmo depois de usar commits convencionais, atirar-lhes um artigo sobre como usar commits convencionais, ensinando-lhes o que o tipo feat significa, o que o tipo fix significa, é na verdade sem sentido. É como dar um livro de culinária avançada a alguém que não sabe cozinhar, sem lhes ensinar como usar ingredientes e utensílios básicos. No entanto, esses artigos estão por toda a internet. Pouco sabem eles, que commits convencionais só podem ser verdadeiramente eficazes quando os desenvolvedores têm pensamento claro e a capacidade de dividir tarefas precisamente.

Portanto, commits convencionais não são maus, mas antes de chegarmos a isso, precisamos de estabelecer a mentalidade de desenvolvimento certa e usar o pensamento científico do desenvolvedor para fazer as coisas.

Pensamento-chave para escrever boas mensagens de commit#

Alterações de código devem fazer uma coisa de cada vez#

No desenvolvimento de software, "fazer uma coisa de cada vez" é um princípio importante. Isso aplica-se não só a escrever código mas também a fazer commit de código. Quando nos focamos numa tarefa ou alteração específica de cada vez, o nosso código torna-se mais claro e as nossas intenções mais explícitas. Este método não só melhora a legibilidade do código mas também simplifica bastante o processo de revisão de código. Os revisores podem mais facilmente entender e verificar o propósito de cada alteração.

Além disso, este método proporciona conveniência para potenciais rollbacks de código. Se ocorrerem problemas, podemos mais facilmente localizar e reverter alterações específicas sem afetar outras partes não relacionadas. Mais importante, quando cada alteração faz apenas uma coisa, a mensagem de commit que descreve esta alteração naturalmente torna-se mais precisa e significativa.

Na prática, isso significa que precisamos de definir claramente a tarefa a ser concluída antes de começarmos a codificar. Após concluir uma tarefa, devemos imediatamente fazer commit do código, em vez de esperar até completar várias tarefas antes de fazer commit em conjunto. Se descobrirmos outras áreas que precisam de modificação enquanto completamos a tarefa atual, a melhor abordagem é anotá-las e tratá-las separadamente após completar a tarefa atual. Por exemplo, quando estás a implementar uma funcionalidade e descobres alguns bugs existentes, o que deves fazer não é corrigir o bug imediatamente juntamente com o teu novo código da funcionalidade, mas sim implementar a funcionalidade primeiro, depois corrigir o bug que descobriste noutro commit, ou corrigir o bug primeiro e depois fazer commit da funcionalidade.

As mensagens de commit na verdade existem antes de escrever código#

Muitos desenvolvedores só começam a pensar em como escrever mensagens de commit após completar o código, mas na realidade, as mensagens de commit deveriam existir antes de começarmos a codificar. Isto é porque as mensagens de commit essencialmente refletem os passos que tomamos para completar uma tarefa. Em outras palavras, são os nossos itens de afazeres.

Quando começamos uma tarefa, devemos primeiro pensar nos passos específicos necessários para completar essa tarefa. Esses passos são a nossa lista de afazeres, e ao mesmo tempo, são as nossas futuras mensagens de commit. Com esta lista de afazeres, cada uma das nossas alterações de código tem um propósito, mantendo-nos focados enquanto codificamos e evitando que nos desviemos da tarefa.

Ainda mais importante, este método pode melhorar significativamente a nossa eficiência. Quando completamos um passo, a mensagem de commit correspondente já está preparada, e podemos usá-la diretamente, reduzindo o tempo gasto a pensar em como descrever a alteração. Ao mesmo tempo, porque estas mensagens de commit são completadas quando temos uma compreensão abrangente da tarefa, são geralmente de maior qualidade e mais informativas.

Suponha que precisas de implementar uma nova funcionalidade de registo de utilizador. Poderias planear os teus passos da tarefa assim:

1. Refatorar o componente existente de formulário para torná-lo mais genérico e reutilizável
2. Criar um formulário de registo de utilizador
3. Implementar integração de API para registo de utilizador
4. Adicionar testes unitários para a funcionalidade de registo de utilizador
5. Atualizar a documentação para a funcionalidade de registo de utilizador

As mensagens de commit correspondentes a estes passos de tarefa poderiam ser as seguintes:

1. refactor: melhorar o componente de formulário existente para reutilização
2. feat: criar formulário de registo de utilizador
3. feat: implementar integração de API para registo de utilizador
4. test: adicionar testes unitários para registo de utilizador
5. docs: atualizar documentação para a funcionalidade de registo de utilizador

Desta forma, tens passos de tarefa claros e correspondentes mensagens de commit concisas antes de começares a codificar. Estas mensagens de commit são realmente a tua lista de afazeres, guiando-te ao longo de todo o processo de implementação da funcionalidade.

À medida que completas cada passo, podes usar a mensagem de commit correspondente para fazer commit do teu código. Isto não só te ajuda a melhor organizar e executar tarefas, mas também garante que cada commit se foca num passo específico, tornando todo o processo de desenvolvimento mais claro e gerenciável. Se precisares de ajustar ligeiramente a mensagem de commit durante a codificação real, podes fazer modificações menores para descrever mais precisamente as alterações reais.

Commits convencionais tornam-se uma escolha natural#

Quando desenvolvemos a mentalidade de desenvolvimento certa, usar Commits Convencionais torna-se natural. Nesta fase, vais achar que escolher o prefixo de tipo apropriado (como feat, fix, refactor, etc.) se torna fácil porque as tuas mensagens de commit já refletem claramente os teus passos de tarefa.

Se quiseres aprender mais sobre como usar commits convencionais, há muitos excelentes artigos disponíveis online. Mas lembra-te, estes padrões só podem ser verdadeiramente eficazes quando construídos sobre a fundação da mentalidade de desenvolvimento certa.

Conclusão#

Escrever boas mensagens de commit não é apenas seguir um certo formato. Requer que mantenhamos um pensamento claro durante o processo de desenvolvimento, clarifiquemos o propósito de cada alteração e consideremos como descrever o nosso trabalho antes de começarmos a codificar.

Commits convencionais são de fato uma ferramenta útil, mas só podem exercer o seu máximo efeito quando combinados com a mentalidade de desenvolvimento certa. Ao praticarmos os dois princípios de "fazer uma coisa de cada vez" e "pensar nas mensagens de commit antecipadamente", podemos não só melhorar a qualidade das mensagens de commit mas também aumentar a eficiência geral do desenvolvimento e a qualidade do código.

Espero que este artigo te ajude a repensar o teu processo de desenvolvimento e te encoraje a tentar estes métodos. Lembra-te, bons hábitos de desenvolvimento levam tempo a cultivar, mas uma vez formados, irão melhorar bastante a tua eficiência de trabalho e a qualidade do código.