Boas práticas ao criar commits no Git

Commits são basicamente unidades de alterações. Acabou de implementar uma nova feature? Refatorou algo específico? Desfez uma alteração? Modificou a versão de algum pacote? Divida essas alterações em pequenas “caixinhas” antes de enviar para o repositório.

Importância

Fazer bons commits é crucial para manter um projeto organizado e manter o controle do seu código. Quando o histórico do git está organizado, voltar para um ponto específico para resolver um bug ou desfazer alguma operação anterior fica muito mais fácil.

Isso é especialmente importante em repositórios com muitos desenvolvedores ao mesmo tempo.

Na prática

Uma coisa de cada vez

Pense antes no tipo de modificação que você fará. E foque apenas nela por um momento. Se vai testar uma classe, faça apenas isso por enquanto, até fazer um commit descrevendo essa alteração. Daí parte para a próxima tarefa.

Deixar para separar todos os commits após horas de trabalho não vai funcionar, ou até pode funcionar, com muito trabalho extra (veja Git - Interactive Staging). Tendo em vista que um mesmo arquivo pode ter duas modificações diferentes, fazer o stage, ou seja, selecionar o que mudou, será mais complicado.

Escreva uma boa descrição do commit

Uma boa mensagem de commit deve: seguir um padrão por todo o projeto, e principalmente, ser clara e bem explicativa. Ela deve sintetizar tudo que mudou, e, ao mesmo tempo, ser simples. Por fim, ser escrita em inglês para ser possível que pessoas do mundo todo a entenda.

Uma dica bem legal é colocar tags na frente da mensagem para definir o tipo de commit, mais ou menos dessa forma: “feat: implement X”. Há várias tags diferentes, dá uma olhada nas mais utilizadas:

• feat: adição de funcionalidade.
• fix: correção de defeito.
• docs: mudança em documentação.
• style: mudança de formatação ou estilo, que não afeta a execução do código (espaço, tabulação, etc.).
• refactor: mudança na organização do código, que não afeta o comportamento existente.
• test: adição ou mudança de um teste.
• chore: adição ou mudança em script de build, que não afeta o código de produção.
• perf: mudança de código para melhoria de desempenho.
• ci: mudança de configuração de integração contínua.
• build: mudança em arquivos de build ou em dependências externas.
• temp: commit temporário, que não deve ser incluído no CHANGELOG.

Use ferramentas de script e linter

Com husky você pode acionar seus testes sempre antes de enviar um commit. Dessa forma você assegura não mandar um código problemático para o repositório remoto — só tome cuidado, se o teste estiver errado, você já manda os dois com problema. 🥲

Outra ferramenta bem legal é um linter de mensagens de commit. Este julgará suas descrições do commit para saber se estão bem formatados e com tags. Gosto muito de usar essa biblioteca aqui: git-commit-msg-linter.

Pratique

Isso são convenções, não regras. Faça do jeito que fique mais claro para você. E não esquente muito a cabeça com isso no começo, se não está acostumado. Com a prática, você desenvolve o hábito de pensar melhor antes de fazer um commit.