Executando verificação de segurança...
15
allbertuu
2 min de leitura ·

Um bom commit no Git não segue o conventional commit – e nem precisa.

Pelo menos, não necessariamente – diferente da obrigação que se fala tanto na internet hoje em dia.

Não parece que todo commit pra ser perfeito precisa seguir a estrutura "feat: add something new and bla bla" ?

Mas muitos se esquecem do óbvio: um dos maiores objetivos de um commit é dizer » o que ele faz, e porquê ele faz «

E olha, mais raro que achar ouro no seu quintal é encontrar um commit que diz o porquê ele existe.

Pensa em você escrevendo a primeira linha de uma redação no Word.
Clica em Salvar. Redação pronta. Partiu descansar?

Ah meu jovem, ainda não. Toda escrita começa com uma palavra e evolui, muda, se descobre, melhora. Com seu código também é assim.

Encare seus commits como parte de uma linha do tempo do teu projeto. A missão delas é » marcar progresso «

O commit é a prova que uma parte dessa grande redação já foi feita (e por quem). Um commit não é feito pra você hoje; ele é feito pra você daqui 1 semana, 1 ano, em diante.

E até para outras pessoas. Que é o caso de trabalhar em uma equipe.

"Mas Alberto, qual a melhor forma de escrever meus commits, então?"

Primeiro saiba que o mais importante é seguir um padrão no projeto. Não precisa reinventar a roda, amigo (a), ou como diria minha Vó, "pra quê enfeitar pavão?"

Se seu time usa de um jeito, vá em frente – inclusive o mesmo idioma (só não vale chinês, pelo bem de todos).

Dito isso, o seu commit deve:
☆ Dizer o que ele faz (de forma simples) – e aqui eu gosto de usar a técnica: "se eu publicar esse commit, ele vai [mensagem do commit]"
☆ Dizer o porquê ele faz (se houver) – lá vai mais uma técnica: "O commit vai [mensagem] porquê [descrição]"

Exemplo:
Mensagem

adicionar estilo de borda no componente Button

Descrição

a remoção do estilo padrão criou um problema de acessibilidade para usuários que usam apenas o teclado para navegação na tela. Esse commit adiciona-o novamente e aplica o style guide da empresa.

Pronto!

Esse é o segredo (anota): independente do formato, seu commit deve dizer o que seu código precisa mudar pra que o motivo pra criação dele se resolva.

Assim você evita dois problemas em repositórios, tão comuns quanto receber mensagem repetida de IA:

  1. Commits que apenas explicam o próprio código
  2. Vários commits que você não faz ideia do porquê foram criados. Nem hoje, nem nunca. (e oremos pra que não descubram quem criou)

Fácil assim. Dificílimo de achar. Experimenta.

Cuidado com commit que diz tudo, menos o importante.

Image

Fonte: https://www.linkedin.com/posts/albertov-albuquerque_git-commit-github-share-7393616541084426240-mBGT?utm_source=share&utm_medium=member_android&rcm=ACoAADcUr88B0Lh2LWHvq6TlcOiCuL4UZ98zwbo

Carregando publicação patrocinada...
4
faelpinho

O VS Code tem um ícone que a IA resume a mensagem de commit, e geralmente é bem útil quando funciona - funciona no Win11 do note do trabalho, mas não no meu note com Manjaro (usando vscode mesmo, não o oss code).
Excelente post!

1
2
samuelsonbrito

Conventional Commit vai muito além de deixar o commit bonito, ele estrutura informação pra gerar changelogs, versionar automaticamente e integrar com CI/CD. É semântica, não estética.

1
allbertuu
  • Autor
    Autor

Justo! Eu mesmo uso ele em alguns projetos! O ponto do post é que um bom commit vai muito além de usar apenas uma estrutura pronta, que pode ser tão vazia de contexto e facilidade de identificar mudanças quanto a caixa de sapato do meu quarto.

Especialmente para devs iniciantes onde a tendência é usar padrões mas não entender o porquê são usados – ou melhor, o que esse padrão buscar resolver em relação ao original.

Repito: consistência é mais importante que perfeição. Não vai mudar o padrão do time só porquê você viu meu post hahah nada de enfeitar pavão. Mas pode ser um bom material pra levar pra conversas internas e avaliar se o uso está cumprindo o propósito dos commits.

2
cleitonper

Se o seu time usa de um jeito, vá em frente

Conventional Commits é igual a democracia, pode não ser o melhor, mas dos que estão disponíveis, é o melhor que temos.

Ele, assim como outros padrões, como por exemplo regras de lint, ajudam a manter um projeto consistente.

Esses padrões, além de facilitar o entendimento do time como um todo, também podem nos ajudar com automatizações. Com conventional commits, por exemplo, podemos gerar release notes automáticas.

Claro que cada um de nós temos nossas preferências, mas na maioria dos casos é mais importante ter um projeto consistente do que cada um fazendo do seu próprio melhor jeito.

Mas é sempre bom dar uma cutucada no que já está estabelecido pra refletirmos se estamos usando algo porque é bom ou só por repetição. Nesse sentido, gostei do artigo, obrigado por compartilhar seu ponto de vista.

1
allbertuu
  • Autor
    Autor

Isso aí, Cleitonper! Nós concordamos com o mesmo ponto rs

Uma boa estrutura e padrão ajudam muitooo, mas precisam ser usadas de forma a melhorar todo o fluxo, não complicar.
Um commit usando o Conventional pode ser tão vazio de contexto e informação do que mudou, quanto a caixa de sapato do meu quarto. O padrão não é ruim, mas pode facilmente ser usado pra outra direção – uma direção diferente do propósito de commits – especialmente por devs iniciantes.

Obrigado pelo comentário!

1
0
1
Hakahay

Particularmente eu coloco o que eu estou fazendo, exatamente para entender o que eu estava fazendo, mas na empresa é um padrão a seguir, então, faça como bem achar para não se perder e respeite as regras e normas de sua empresa.

1
-2
misterioso013

Mas isso já está no automático do Dev.
Termina a Task em cima do prazo, passou os testes...

git add .
git commit -m "feat: hmmm..."

....
O que essas alterações fazem?

git commit -m "feat: garante meu salario ..."

Nao...

git commit -m "feat: add todolist to codebase"

Acho que só ligam para os commits o pessoal que trabalha no Review ou o pessoal de Open Source, até porque você precisa ir lá bonitinho fazer seu PR e explicar o que foi feito. A unica coisa boa disso seria justamente o "feat:", "docs:", "chore:", "refactor:"

1
allbertuu
  • Autor
    Autor

Entendo teu ponto de vista.

Mas precisamos lembrar que commits servem pra logs, e responsabilização (git blame por exemplo).

São essenciais para marcar progresso e essenciais para evoluir de pouco em pouco – o suficiente pra que logo depois de implementar algo, 1 ou 2 dias depois já esteja revisado por outro dev. Isso é crucial para manter a qualidade e errar rápido.

Obrigado pelo comentário!