Como programadores, dar nomes para as coisas (variáveis, funções, etc) faz parte da nossa rotina diária. Em linguagens de programação temos que seguir uma convenção, isto é, um modelo para nomear e isto também se aplica para as mensagens de commit no Github.
É bem difícil colocar em mais ou menos 50 caracteres as mudanças feitas no seu código. Quando não se está acostumado com as boas práticas, você adiciona uma nova feature, faz refatoração de código, cria novos testes unitários para suas funções e coloca tudo isso dentro de um mesmo commit e faz o push pro seu repositório no Github.
O grande macete é pensar nos seus commits como checkpoints do seu código.
Como num jogo, toda vez que você ganha um novo item, ou derrota um boss é interessante você salvá-lo, para não perder o progresso. O mesmo vale para seu código e seus commits.
Por exemplo, criados novos testes, faça um commit com a mensagem test: criação de testes unitários para função X. Percebe que além de uma mensagem clara, resumindo o que foi feito naquele commit, temos um nome identificando qual é o tipo de commit.
Peraí, commits possuem tipos?
Não necessariamente você é obrigado a colocar os tipos, porém em projetos open-source é comum essa prática, visto que muitos desenvolvedores estão contribuindo para o repositório e é necessária uma organização.
Considere o repositório do framework Angular, ferramenta a qual permite criar componentes visuais com Javascript de maneira mais automática:
Dentro do próprio repositório existe um arquivo, em inglês, ensinando os desenvolvedores como escrever a mensagem de commit.
Quais são os tipos?
Os tipos mais importantes, sem dúvidas, são fix e feat. O primeiro serve para denotar correção de bugs no código, enquanto o segundo define uma nova funcionalidade no código.
Além disso, temos outros tipos:
- chore: mudanças que não estão ligadas à funcionalidade do projeto, mas necessárias para que o projeto funcione (manutenção de arquivos de integração contínua, processos de compilação). Basicamente, infraestrutura do código
- docs: commits relacionados à documentação apenas
- perf: mudanças referentes à performance do código
- style: estilização do código (adição de novas linhas em branco, indentação)
- refactor: refatoração de código, não corrige bugs e nem adiciona novas funcionalidades
- test: correção de testes ou criação de novos testes
Outros fatores importantes
Existem mais especificações sobre qual a maneira correta de um commit, por exemplo, definir o escopo de onde ocorreu a mudança: fix(api): correção de bug na criação de usuário.
Contudo, o essencial é separar os commits em tipos, isso já deixa o ambiente muito mais organizado e a adição do escopo na mensagem só deve ser feita, caso o projeto seja complexo, ou se for instrução da empresa ou time em que se está trabalhando.
Além disso, eu desaconselho colocar emojis nas mensagens de commit, porque polui visualmente e - na maioria dos casos - confunde outros desenvolvedores.
Em suma, o mais importante é deixar claro o que foi feito no commit, para que outros possam entender como o projeto está evoluindo.
Se desejar entrar em contato: meu linkedin. Estou à disposição para networking.
Top comments (3)
excelente post! confesso que às vezes acabo não seguindo uma padronização para informar sobre o que é o commit, embora já faça commits pensando em checkpoints, então vejo que preciso melhorar nesse ponto.
parabéns pelo post, maninho! importantão a galera seguir aquele padrão dentro da firma pra não sair um monte de :
"wip"
"wip foda"
"deu ruim aqui"
Incrivel o post primo! Commits de qualidade já salvaram meu dia diversas vezes