Commits convencionais não vão salvar suas mensagens de commit

Uma rápida pesquisa na internet revelará uma infinidade de artigos ensinando você a escrever mensagens de commit. 90% desses artigos dizem para você usar commits convencionais. No entanto, um número considerável de desenvolvedores ainda luta com isso. Eles sabem que devem seguir essas convenções, mas acham difícil aplicá-las na prática. Toda vez que eles fazem um commit de código, ficam angustiados sobre se devem escrever "refactor" ou "chore". Já vi até projetos onde a lista de mensagens de commit consiste inteiramente da mesma mensagem: "feat: add page", porque escrever mensagens de commit era muito desafiador para eles, e eles simplesmente desistiram.

É muito cedo para falar sobre commits convencionais#

Não estou dizendo que commits convencionais são ruins. Eles têm muitos benefícios conhecidos:

• Eles fornecem um formato unificado, tornando as mensagens de commit mais padronizadas
• Eles são fáceis de serem analisados por ferramentas automatizadas, permitindo a geração automática de changelog
• Eles ajudam os membros da equipe a entender o propósito e o escopo das mudanças de código
• Eles permitem a rápida identificação de diferentes tipos de mudanças de código

No entanto, quando um desenvolvedor ainda está lutando para escrever boas mensagens de commit mesmo depois de usar commits convencionais, jogar um artigo sobre como usar commits convencionais, ensinando a eles o que significa o tipo feat, o que significa o tipo fix, é na verdade sem sentido. É como dar um livro de receitas avançado para alguém que não sabe cozinhar, sem ensiná-los a usar ingredientes e utensílios básicos. No entanto, esses artigos estão por toda parte na internet. Poucos sabem que commits convencionais podem realmente ser eficazes quando os desenvolvedores têm um pensamento claro e a capacidade de dividir tarefas de forma precisa.

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

Pensamento-chave para escrever boas mensagens de commit#

Mudanças 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 se aplica não apenas a escrever código, mas também a fazer commits de código. Quando nos concentramos em uma tarefa ou mudança específica de cada vez, nosso código se torna mais claro e nossas intenções mais explícitas. Esse método não apenas melhora a legibilidade do código, mas também simplifica enormemente o processo de revisão de código. Os revisores podem entender e verificar mais facilmente o propósito de cada mudança.

Além disso, esse método oferece conveniência para potenciais rollbacks de código. Se problemas ocorrerem, podemos localizar e reverter mudanças específicas mais facilmente, sem afetar outras partes não relacionadas. Mais importante ainda, quando cada mudança faz apenas uma coisa, a mensagem de commit descrevendo essa mudança naturalmente se torna mais precisa e significativa.

Na prática, isso significa que precisamos definir claramente a tarefa a ser completada antes de começarmos a codificar. Após completar uma tarefa, devemos imediatamente fazer o commit do código, em vez de esperar até que múltiplas tarefas sejam completadas antes de fazer um commit em conjunto. Se descobrirmos outras áreas que precisam de modificação ao completar a tarefa atual, a melhor abordagem é anotá-las e lidar com elas separadamente após completar a tarefa atual. Por exemplo, quando você está implementando uma funcionalidade e descobre alguns bugs existentes, o que você deve fazer não é consertar o bug imediatamente junto com o seu novo código de funcionalidade, mas sim implementar a funcionalidade primeiro e, em seguida, consertar o bug que você descobriu em outro commit, ou consertar o bug primeiro e depois fazer o commit da funcionalidade.

Mensagens de commit realmente existem antes de escrever o código#

Muitos desenvolvedores só começam a pensar em como escrever mensagens de commit após completar o código, mas na realidade, mensagens de commit devem existir antes de começarmos a codificar. Isso se deve ao fato de que mensagens de commit essencialmente refletem os passos que tomamos para completar uma tarefa. Em outras palavras, elas são nossos itens de tarefa a fazer.

Quando começamos uma tarefa, devemos primeiro pensar sobre quais passos específicos são necessários para completar essa tarefa. Esses passos são nossa lista de tarefas a fazer e, ao mesmo tempo, são nossas futuras mensagens de commit. Com essa lista de tarefas, cada uma de nossas mudanças de código tem um propósito, mantendo-nos focados enquanto codificamos e impedindo-nos de desviar da tarefa.

Mais importante ainda, esse método pode melhorar significativamente nossa eficiência. Quando completamos um passo, a mensagem de commit correspondente já está preparada, e podemos usá-la diretamente, reduzindo o tempo gasto pensando em como descrever a mudança. Ao mesmo tempo, como essas mensagens de commit são completadas quando temos um entendimento abrangente da tarefa, geralmente elas são de maior qualidade e mais informativas.

Suponha que você precise implementar uma nova funcionalidade de registro de usuário. Você pode planejar seus passos da tarefa assim:

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

As mensagens de commit correspondentes a esses passos da tarefa podem ser as seguintes:

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

Dessa forma, você tem passos claros da tarefa e mensagens de commit concisas correspondentes antes de começar a codificar. Essas mensagens de commit são realmente sua lista de tarefas a fazer, guiando você por todo o processo de implementação da funcionalidade.

À medida que você completa cada passo, pode usar a mensagem de commit correspondente para fazer o commit do seu código. Isso não apenas ajuda você a organizar e executar melhor as tarefas, mas também garante que cada commit foque em um passo específico, tornando todo o processo de desenvolvimento mais claro e gerenciável. Se você precisar ajustar ligeiramente a mensagem de commit durante a codificação real, pode fazer pequenas modificações para descrever mais precisamente as mudanças reais.

Commits convencionais se tornam uma escolha natural#

Quando desenvolvemos a mentalidade de desenvolvimento certa, usar Commits Convencionais se torna natural. Nesse estágio, você descobrirá que escolher o prefixo de tipo apropriado (como feat, fix, refactor, etc.) se torna fácil, porque suas mensagens de commit já refletem claramente seus passos de tarefa.

Se quiser aprender mais sobre como usar commits convencionais, há muitos excelentes artigos disponíveis online. Mas lembre-se, esses padrões só podem ser eficazes quando construídos sobre a base da mentalidade de desenvolvimento correta.

Conclusão#

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

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

Espero que este artigo ajude você a repensar seu processo de desenvolvimento e encoraje você a tentar esses métodos. Lembre-se, bons hábitos de desenvolvimento levam tempo para cultivar, mas uma vez formados, eles melhorarão muito sua eficiência de trabalho e qualidade do código.