No incrível mundo do desenvolvimento de software ou web, o controle de versão é essencial para todo desenvolvedor que trabalha em um projeto com outros desenvolvedores.

Um dos sistemas de controle de versão mais usados ​​é o Git, que ajuda os desenvolvedores a seguir as mudanças, voltando a estados anteriores de forma eficaz e trabalhando em equipe em seus projetos. Mas, sendo funcional, o Git só se mostra eficaz se os commits forem gerenciados corretamente. Neste artigo, abordaremos os commits bons e ruins, explicando as melhores práticas para ter um histórico de commits claro, informativo e útil.

O que é um commit?
No Git, um commit se refere ao estado do seu código em um ponto específico no tempo. Commits com os metadados (autor, registro de data e hora, mensagem de commit etc.). Commits são usados ​​para salvar a progressão, declarar mudanças e mesclar partes desenvolvidas com o trabalho de outros.

Características de um bom commit
Atômico e focado: um commit deve ser atômico – ele deve representar uma e apenas uma mudança lógica. Não misture várias mudanças independentes em um commit.

Mensagem de Commit Descritiva: Uma mensagem de commit descritiva explica claramente o que o commit faz e por que a mudança foi feita. Ela deve fornecer contexto suficiente para que outros (e você mesmo no futuro) entendam a mudança sem ler o código.
Exemplo:

# Boa mensagem de commit
git commit -m “Corrigir exceção de ponteiro nulo correto no login do usuário”
# Mensagem de commit ruim
git commit -m “Corrigir bug”

Siga as Diretrizes de Commit Convencionais: Você pode usar as diretrizes de commit padrão para manter seu histórico do git limpo, consistente e fácil de ler. Normalmente, essas diretrizes são interpretadas na forma de tipo (feat, fix, chore, refactor docs) e um breve resumo, além de ocasionalmente uma longa explicação ou REF para outros problemas relativos.
Exemplo:

# Boa mensagem de commit seguindo as diretrizes convencionais
git commit -m “feat(auth): adicionar autenticação baseada em JWT”
git commit -m “fix(login): resolver condição de corrida no fluxo de login”

Testado e Verificado: Certifique-se de que as alterações em seu commit foram testadas e executadas corretamente. Código quebrado/não testado pode atrapalhar o fluxo e outros membros.
Escopo adequado: Defina o escopo de seus commits adequadamente. Por exemplo, se você estiver trabalhando em um recurso específico ou corrigindo um bug, garanta que todas as alterações relacionadas a essa tarefa sejam incluídas em um único commit. Evite alterações parciais que podem deixar a base de código em um estado inconsistente.

Exemplo:

# Bom commit com escopo adequado
git commit -m “refactor(auth): dividir lógica de autenticação em módulo separado”
# Commit ruim com escopo misto
git commit -m “refactor e pequenas correções”
Características de um commit ruim
Grande e sem foco: Um commit com muitas alterações é um commit ruim. Isso dificulta entender o que o commit faz. Commits grandes e sem foco são desafiadores para revisar e depurar.
Exemplo:

# Commit ruim
git commit -m “Atualizar projeto”
Mensagens vagas ou enganosas: Mensagens de commit vagas ou enganosas não fornecem informações úteis sobre as alterações. Essa falta de detalhes pode causar confusão e dificultar o rastreamento do histórico de alterações.
Exemplo:

# Mensagem de commit ruim
git commit -m “Stuff”
Alterações não relacionadas: combinar alterações não relacionadas em um único commit dificulta o isolamento de alterações específicas, potencialmente introduzindo bugs e complicando o processo de revisão.
Exemplo:

# Commit ruim
git commit -m “Atualizar readme e corrigir problema de login”
Código incompleto ou não testado: fazer commit de código incompleto ou não testado pode interromper o fluxo de trabalho, causando problemas para outros membros da equipe e potencialmente interrompendo a compilação.
Falta de contexto: um commit ruim geralmente não tem contexto, dificultando o entendimento do motivo da alteração. Isso pode levar a confusão e dificuldades ao revisitar o código no futuro.

Melhores práticas para bons commits
Faça commit com frequência, mas não com muita frequência: busque um equilíbrio entre fazer commit com muita frequência e não o suficiente. Cada commit deve representar uma alteração significativa. Nunca envie alterações não relacionadas em um único commit.

Escreva mensagens claras e descritivas: suas mensagens de commit devem explicar o que o commit faz e por que você fez a alteração.
Use Branches Efetivamente: Use branches de recursos para novos recursos, correções de bugs e experimentos. Crie Pull Requests para esses branches e o gerente de projeto ou administrador revisará seu código e os mesclará no principal.
Revise e compacte commits: Se você for o proprietário do projeto, líder, administrador ou alguém revisando o código, antes de mesclar um branch, revise e compacte commits pequenos ou de correção em unidades lógicas. Essa prática mantém o histórico de commits limpo e fácil de seguir.
Automatize os testes: Use ferramentas de integração contínua para testar automaticamente seu código com cada commit. Isso garante que suas alterações sejam verificadas e reduz o risco de introduzir bugs.
Use Husky: Usar uma biblioteca como husky pode melhorar suas habilidades no git. Ela não permite o commit se você estiver quebrando as regras configuradas no husky.

Conclusão

Bons commits são importantes para manter um histórico de projeto limpo e compreensível no Git. Ao seguir as melhores práticas, como manter os commits atômicos, escrever mensagens descritivas e garantir que as mudanças sejam testadas, você pode melhorar a colaboração e tornar seu projeto super sustentável. Um histórico de commits bem gerenciado é um recurso inestimável para você mesmo no futuro, sua equipe ou para novos colaboradores.

Ao seguir as diretrizes acima, você tornará mais fácil para todos os envolvidos no projeto entender, revisar e desenvolver seu trabalho. Feliz commit!