Executando verificação de segurança...
14

✉️ Método para escrever mensagens de commits

É sempre muito bom quando estamos fazendo um commit, pois significa que nosso projeto está evoluindo ou bugs estão sendo corrigidos. O commit irá criar um novo registro na linha do tempo do nosso projeto, e isso é extremamente importante no dia a dia de uma empresa, pois ajuda a equipe a identificar erros no sistema ("Até determinado commit, estava funcionando, após este commit começou a bugar"), facilitar a organização de um projeto que é desenvolvido por várias pessoas, entre outras vantagens. Cada commit exige uma mensagem, que na prática deveria ser uma explicação do que aquele commit fez/corrigiu, mas na realidade escrevemos qualquer coisa (já vi mensagens do tipo "asdasdasd" ou "ok"), pois não temos tempo de ficar pensando em uma mensagem, o importante é que o problema foi solucionado, correto ? Não.

A mensagem do commit é tão importante quanto ao problema que ele resolve.

Beleza Matheus, mas este projeto só eu desenvolvo ele, não tem o porque ficar pensando em mensagem de commit.

Dois pontos sobre este pensamento:

  1. Passado um tempo, você identifica um bug na aplicação. Não conseguindo identificar a origem do problema, você recorre ao histórico de commits, para tentar reverter o processo, e encontrar em qual funcionalidade/componente o erro está ocorrendo. Garanto que será um trabalho ardiloso, visto que criou commits com mensagens nada descritivas, e o que era pra ser um processo simples, acaba se tornando um pesadelo.
  2. Mesmo que só você esteja desenvolvendo o projeto, já é uma boa prática ir treinando a escrita de mensagens descritivas de um commit, pois quando você precisar trabalhar em equipe, já vai estar acostumado com tal prática.
Entendo a importância, mas tenho dificuldade em criar as mensagens

Eu também tinha essa dificuldade, mas aprendi algo que me ajudou muito a escrever as mensagens do commit, e vou compartilhar com vocês:

O segredo está na forma em que você enxerga o commit. Antes de escrever a mensagem, faça uma pergunta a si mesmo: O que esse commit faz/resolve ?

A resposta dessa pergunta será a mensagem do seu commit. Sim, é simplesmente isso. A primeira palavra sempre será um verbo já conjulgado na terceira pessoa (ELE), exemplo:

  • Remove a listagem de usuários que não possuem um telefone
  • Altera a cor dos campos quando os mesmos estão selecionados
  • Adiciona funcionalidade que permite a remoção de um usuário

Garanto que será muito mais simples e rápido criar as mensagens, pois logo após você se perguntar sobre o que o commit faz, a resposta virá automaticamente na sua cabeça, além de criar uma padronização para seu projeto.

Espero que tenha ajudado. Lembrando que existem outras formas de se padronizar commits, só quis trazer a que mais me agrada. Se você tem alguma diferente, deixa aqui nos comentários. Abraços!

Carregando publicação patrocinada...
3

Ótima publicação, inclusive, aos que comentaram que desejam "padronizar" commits de seus times, recomendo o uso do Husky e do Commitizen.

Husky permite que sejam disparados "hooks" na realização do commit, para validar, por exemplo, a indentação do código.

Já o Commitizen gera uma "interface" no terminal, guiando os passos do commit, para padronizar prefixos (feat:, fix:, docs:), número da issue, tamanho mínimo/máximo da mensagem do commit, entre outras coisas.

1
1
3

Boa! Vou usar essas dicas para convencer a galera da minha equipe, porque o que mais vejo de comentários de commit é "Ajustes"... isso me mata hahaha comentei uma vez e me disseram "Eu gosto de ser simples e direto". Mas enfim, em vez de só criticar vou também tomar uma ação agora o/

1

"Ajustes" é ótimo kkkkkkkkkkkkkkkkkk Eu já considero este método que mostrei simples e direto. Tem alguns que realmente são bem detalhados, e acho que a escolha depende do tamanho e tipo do projeto.

1
3

Para mim um mensagem de commit bem escrita vai além de organização e serve como um checkbox do projeto e traz uma sensação boa como a de finalizar uma lista de tarefas imensa em pouco tempo.

2

Tô fazendo pequenos projetos para praticar Node e tentando aplicar isso para que o meu próprio pensamento se organize. Acho que outra coisa legal é fazer pequenos commits de vez em quando para não se perder, já teve situações que eu fiz tanta coisa antes de fazer o commit que nem sabia como resumir o que tinha feito.

1

Mesmo pra projetos pessoais e de estudo, é muito bom vc dividir seu trampo em pequenas "features" e commitar sempre...
É legal vc seguir um padrão de dividir em branches também. Pelo menos pra mim, ajuda a se orientar na hora de ar manutenção em projetos mais antigos (sem contar que vc vai usar no trabalho, então já dá aquela treinada heheh)

1

Sim, essa questão de pequenos commits ainda estou tentando acostumar. As vezes eu consigo aplicar, ai em determinado momento eu vou ver e já fiz diversas modificações sem commitar kkkkk. Mas realmente é uma boa separar em pequenos commits.

2

Uma vez vi um comentário bem legal, que fala que quando os commits são bem feitos, o git log conta a história daquele projeto, achei sensacional! Eu até tento utilizar conventional commits sempre que posso, mas na empresa que eu trabalho ainda não temos isso como padrão

1

Muito massa esse ponto de vista. Essa adaptação não vai ocorrer da noite pro dia na empresa, mas voce pode começar a mudança por você, e explicar para os outros os benefícios dessa padronização.

2

Dicas valiosíssimas!

No início desse semestre o meu amigo de grupo de TCC me apresentou ao Conventional Commit, onde pude aprender demais sobre a importância da padronização de commits na aplicação. Depois de cerca de 1 mês utilizando a técnica, decidi voltar um pouco no tempo em meu repositório nos projetos que eu não utilizava o commit semântico e eu simplesmente não entendia NADA do que eu havia feito ali. E era um projeto simples, mas eu precisava abrir cada commit e estudar o código pra entender o que diabos eu havia feito de modificação.

As suas dicas com certeza irão ajudar bastante a organização dos repositórios da galera!

Recomendo também pra galera que já tem um pouco mais de conhecimento sobre o Git, estudar sobre o Git Flow. Ele vai ser importantíssimo, principalmente em projetos colaborativos e de grande escopo.

2

Hoje nas empresas é muito comum o uso das estruturas recomendadas pela Convenção de Commits

A especificação Conventional Commits é uma convenção sobre as mensagens de confirmação. Ele fornece um conjunto fácil de regras para criar um histórico de confirmação explícito; o que facilita a escrita de ferramentas automatizadas.

No começo parece ser confuso, o que usar, quando usar e onde usar? rsrs
Mas você acaba se habituando e se acostumando com o padrão.

Gostaria de ressaltar o segundo ponto da questão:

"mas este projeto só eu desenvolvo ele, não tem o porque ficar pensando em mensagem de commit."

Fora ser uma boa prática, lembre sempre que "Quem fornece ajuda, recebe ajuda!". Você especificar bem um commit, ajuda outros desenvolvedores futuros a entenderem o caminho que foi tomado e o que foi modificado... Claro que ajuda na prevenção e resolução de bugs (já que você está versionando o seu código), mas creio que o principal do commit é ajudar na comunicação do time de devs, já que temos que cumprir uma série de etapas("commit, abre pullrequest, solicita(e faz) o code review, mergeia a PR na development, teste em hml, mergeia a development na main... Enfim...)para podermos entregar o "produto" final...

Creio que é uma boa seguir essa estrutura que o Conventional Commits nos oferece...
O kunzgabriel respondeu esse post, dando a dica de usar o Husky e o Commitizen, o que eu também recomendo! Abaixo vou deixar o link das documentações e cheat sheet:

2

Maravilha! Estou tentando me acostumar a usar versionamento/git, mas é um processo sempre complicado. E o commit é aquela etapa que ainda preciso entender bem.

Às vezes passo um dia trabalhando e mexo em vários arquivos de algum projeto pessoal e 'commito' tudo de uma vez, fica uma bagunça. Penso que pelo discutido aqui, preciso me organizar para dar commit a cada etapa (ou realizar o commit de cada arquivo separadamente).

1

Acho que commitar as etapas seria um bom caminho, o caso tem que ser bem específico para commitar apenas o arquivo(ex. Atualização do README.md)
Não sei se você costuma fazer um refinamento técnico das tarefas, mas quando pega os pontos que você levantou a respeito da feature a ser trabalhada, fica mais fácil commitar pq já tem meio que um check list de etapas criado, ai a cada etapa finalizada você vai commitando...

Um exemplo breve para ilustrar:

Você precisou fazer um formulário de newsletter e os seguintes componentes precisam ser criados confome as etapas abaixo:

  • Configuração do endpoint do Serviço de cadastro
  • Container do formulário onde vou colocar meus inputs
  • input de texto para o usuário digitar o e-mail
  • Um botão
    • Evento do botão com o serviço de cadastro

"Ai beleza, você resolveu commitar cada etapa após finalizada... A estrutura ficaria próximo dessa organização:"

  • feat: endpoint do serviço de cadastro
  • feat: criação do container utilizando display flex
  • feat: input de texto estilizado e configurado
  • feat: botão estilizado e disparando o evento
  • feat: ajustes finos e form de newsletter funcionando

obs. só dei exemplo do feat para simplificar, mas têm muito mais variações de etapas, feat, chore, ci, refact...

Lembrando:

feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).

Tradução: feat: uma confirmação do tipo introduz um novo recurso na base de código (isso se correlaciona com MINOR no Versionamento Semântico)

Resumindo, fica tranquilo que com o tempo você vai se acostumando com a padronização dos seus commits 👊😉

2

Muito obrigado por seu artigo, eu estou entrando agora na área da programação e artigos como este me ajudam muito a saber como me comportar e não atrapalhar meu time.

1

Boa. Tem pessoas que trabalham a anos na área e que não aplicam esta prática, ou qualquer outra semelhante. Entrar como Junior ou estágiario já conhecendo esse padrão é um bom diferencial.