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

2 min de leitura ·

Guia de bolso para Commits Semânticos

Quem nunca se deparou (ou até mesmo escreveu 🥸) uma mensagem de commit "updates". Na hora de escrever parece inofensivo, mas quando alguém precisa revisar algo no código isso pode se tornar um problemão 🤯

Objetivo da mensagem de commit

Resumindo: descrever de forma rápida o objetivo daquela alteração no código, para facilitar a vida de quem for revisar o código (Inclusive para você mesmo)

Não superestime a sua memória, quem nunca deixou uma task pela metade na sexta e quando voltou na segunda não fazia ideia do que estava fazendo. Lembre-se que no futuro você não vai ter todo o contexto que você tem no momento que está codando

Vamos lá

"feat: [...]": Usado para criação de ~~novas features~~, endpoints, services e etc
```
feat: create user service
```

"fix: [...]": Solução de erros, bugs e afins

fix: error on create user without profile picture

"refactor: [...]": Quando for refatorar um trecho de código
```
refactor: refactor create user service
```
"chore: [...]": Alterações que não o funcionamento do sistema nem em testes automatizados, como alterações no .gitignore, eslint, README.md e etc
```
chore: use prettier on eslint rules
```
"style: [...]": Alterações de estilo que não influenciam no sistema
```
style: change background color
```
"build: [...]": Alterações que impactam apenas o build do projeto
```
build: create deploy config file
```
"test: [...]": Criação ou modificação de testes automatizados
```
test: testing create user service
```

Algumas dicas

Os padrões podem variar entre empresas, mas geralmente seguem um padrão muito parecido com isso
Crie o hábito de escrever as mensagens em inglês, é a linguagem universal na programação e você nunca sabe quando vai estar em um projeto com desenvolvedores de fora 😉
Alguns projetos usam ferramentas como husky para fazer o lint das mensagens de commit, vale a pena dar uma olhada
Se você usa VSCode eu recomendo a extensão gitlens

Fonte: https://www.linkedin.com/posts/danielsarmentodossantos_n%C3%A3o-prestava-muita-aten%C3%A7%C3%A3o-na-import%C3%A2ncia-activity-7026001076793323520-CYC6?utm_source=share&utm_medium=member_desktop

Guia maravilhoso, @JeanJr! Depois que você começa a aprender Git e Github e os projetos começam a ficar um pouco maiores, realmente se faz necessário que os commits estejam escritos de forma semântica. Quero também contribuir para sua publicação com outros tipos de commits semânticos que eu conheço:

"docs: [...]": Usado, como o nome já diz, para documentação, README.md, etc.

    docs: created contributing guide

"perf: [...]": Usado para qualquer commit que esteja relacionado a performance.

    perf: improvement on site loading

Eu descobri que existia commits semânticos com esse repositório do iuricode:
https://github.com/iuricode/padroes-de-commits.

Vale a pena dar uma olhada!

lucasaltenhofen

Muito bom esse assunto, aqui na empresa em que trabalho, utilizamos como base na definição da padronização interna de commits a especificação do Conventional Commits

Inclusive uma informação importante que adicionamos junto na padronização é um identificador da demanda (id da issue/card/task) relacionada ao commit, ajuda muito na investigação do código.

Espero ter contribuido com o assunto 👍

conventional commits é o caminho. usar ele junto com hooks no git para obrigar que todas suas regras sejam seguidas é vida.

quer ir além? usa para versionar automaticamente e fazer releases.

Cara eu adorei, vou utilizar em todos os meus commits a partir de agora e tenho certeza que este post vai ajudar muitas outras pessoas !!!

Boa!

Concordo demais, uma boa prática é conversar com a equipe para definir alguns outros padrões, vai que é necessário um parâmetro especial como "config: [...]" ou similar, e manter isso documentado também não é má ideia, pensando que sua equipe vai ter certeza do que está sendo escrito.

Outro ponto é: Será que é necessário escrever em inglês?

Vale verificar a necessidade de fazer em inglês as mensagens de commit, pode ser que sua equipe se sinta mais a vontade e também mais produtiva ao escrevê-los em português, e dependendo do projeto, isso não cria um impacto tão severo, assim como o próprio Filipe Deschamps fala neste vídeo antigo

Use o git commit sem a flag -m

Citando um artigo que fiz um tempo atrás: "Busque sempre criar um commit sem a flag -m, pois assim é possível adicionar mais detalhes."

Gosto muito de fazer dessa forma, pois abre um editor de texto da sua preferência e ali pode-se descrever melhor as mudanças!

Se quiserem verificar esse artigo, basta clicar aqui

Enfim... Diálogo e alinhamento ajudam as equipes a se entenderem

Abraço e obrigado pela postagem, muito proveitosa!

@ItanuRomero, comentário explêndido! Eu ainda não tinha assistido esse vídeo do Deschamps, a mensagem que ele passa é sensacional, fora da curva.

Gostei bastante do seu artigo sobre Git, não sabia que dava pra fazer o git commit sem o -m. Eu até fazia as descrições no mesmo comando, desse jeito:

    git commit -m ":feat: Added somethings" -m $'- Something on line 56 \n- Something on src/App.jsx \n- Something on package.json'

Sim, eu matei os commits semânticos agora, mas é só de exemplo, desculpa...
Eu uso o $' ', porque eu uso o bash como terminal e ele só aceita assim.

Agora eu vou fazer os commits direto pelo editor de texto do terminal, muito melhor e mais fácil de mexer. Obrigado pela sua contribuição!!

E também vou salvar seu artigo para poder ler com calma depois e poder aprender bastante sobre Git.

Íncrível, fico muito feliz em ter ajudado!

Eu puxei várias informações de vários vídeos diferentes e de documentações também, mas é um dos artigos que mais tenho orgulho :)

Esbarrei nesse assunto recentemente e comecei a usar, mas so conhecia os mais comuns, fix e add. Ter uma lista mais extensa ajuda bastante! Obrigado.

Excelente! Há tempos tinha vontade de dar uma melhorada nos meus commits e esse seu post me deu uma motivada, pois facilitou muito minha busca!

Nossa, massa demais! alguns desses eu não utilizava, mas faz todo sentido.

Brabissimo Jean, já havia visto algo do tipo, mas nada muito profundo, publicação muito bem estruturada.

boa! a equipe seguindo todo essa padrão não tem erro na análise e localização dos commits

Uso commitizen nos meus projetos pra ajudar nesse sentido.

https://github.com/commitizen/cz-cli

Basicamente rodo git cz e um menu interativo ajuda a escrever a mensagem exatamente no estilo citado neste artigo.

Também usamos no trampo e é uma mão na roda pra atualizar o Changelog e também Release Notes uma vez que os commits respeitam um padrão de mensagens.

No README.md do repositório têm instruções de instalação e uso.

Opa, estava buscando isso mesmo, apesar que acredito precisar dar uma atenção maior e aprofundar no assunto, começo minha carreira como dev na segunda-feira!

Autor

Que legal Luciano! Muito sucesso para você, relaxa e aproveita a jornada

Husky é uma m*. Não recomendo. A não ser que vc seja muito indisciplinado, preguiçoso e seu código seja muito ruim. Aí é melhor usar mesmo, pra não atrapalhar os bons desenvolvedores.

Autor

Eu comentei que existem projetos que usam husky, se você cair de paraquedas em algum que use não vai ter a escolha de usar ou não. A menos que seja um projeto solo, ou um projeto que não vai crescer.

Mas que é as vezes é chato quando a gente tá com pressa você tem toda razão 😅

Já vou começar a colocar em prática, acho que mesmo pra projetos pessoas e na fase de aprendizado já faz com que se crie bons hábitos. Ótima publicação !

eu pensei em fazer isso tantas vezes. obrigado por ter feito!!!

pedrosantos3010

Eu ajudei a minha empresa a padronizar um pouco os commits, aqui fazemos commits em português, pois o projeto é especifico pro br e contém termos que seriam muito difíceis para nós programadores traduzirem corretamente para o inglês (mercado de energia elétrica). Criamos a nossa própria versão de commits semânticos usando também o gitmoji, é muito satisfatório ver os commits padronizadinhos (exemplo: https://prnt.sc/eBjB8uLyzpyc)

ThiagoHenriqueSantos

Ótima publicação!
Nunca tinha visto algo sobre escrever commits semânticos. Apesar disso, eu já venhos escrevendo commits parecidos com isso, mas tenho alguns pontos em que posso melhorar, como padronizar melhor as "palavras chaves" inciais e resumir mais as descrições de alguns commits, que acabo descrevendo detalhes. Essa publicação vai ajudar muito!
Obrigado!

Sensacional! Sempre fico com dúvidas do que colocar de mensagem nos commits. Tem uma extenção do VSCode que ajuda bastante nisso: Conventional Commits

Gostei demais, eu estava mesmo querendo um documento tão simples explicando isso. Sobre os commits só o que me incomoda é ter que ser breve, as vezes eu sinto que a mensagem do commit não explica tudo o que eu fiz, não sei se faço coisas de mais em um unico commit. Qual é o certo a se proceder, fazer mais commits com descrições breves ou menos commits que alterem bem mais código e com descrições longas?

Cara isso depende muito do projeto. Se você fizer muitas alterações que vão impactar o sistema, eu acho que descrever tudo o que foi feito é legal, mas tem que descrever bem resumidamente para que não fique muito extenso. Uma dica que um senior me passou uma vez é "descrever com muitos detalhes, porém em poucas palavras", mas isso é um processo de aprendizado com o tempo você pega jeito do que colocar e tal, esses commits semânticos já são um bom passo pra resumir tuas tarefas.

Se a descrição do commit não cabe no titulo dentro do limite do conventional commits, significa que você está fazendo muita alteração em um só commit. :-)

Uma boa prática é referenciar ao issue que descreve a tarefa que você está executando.

feat(login): allow social login 

implements a social login method using package laravel/socialite package.

refs: #2384

Desta forma tem uma descrição clara porém resumida do commit. Outros detalhes podem estar na conversação da issue #2384.

Mesmo em projetos solo, eu abro issues para todas as tarefas, e todos os commits são referenciados, assim dentro da issue eu também vou ter uma referência a quais commits desenvolveram aquela tarefa.

Na issue eu escrevo meus pensamentos, motivações para aquela feature, passos para reproduzir um determinado bug, e inclusive passos que usei até chegar a causa do problema. acredite, no futuro você vai ter um bug parecido, e vai lembrar que escreveu lá a solução. as vezes isso vai te poupar horas ou até dias.

leonardorcamargo

Show demais!
Definiu de forma clara e objetiva a base para bons commits :)

Na empresa onde trabalho mantemos uma documentação onde criamos o nosso próprio padrão, partindo de uma base muito parecida com essa sua.

Algo que fez muito sentido para nós, foi inserir o escopo que estamos atuando em alguns commits, então temos esta estrutura, sendo o escopo um campo opcional:

<tipo>(<escopo>): <resumo>

kkk aquele commit genial que a gente não sabe o que está fazendo sem ler o código.
Ótimas dicas, gostei bastante.
Vou tentar implementar.

edsonjuniornarvaes

Utilizo essa prática de commits semânticos faz uns 2 anos e desde então acabou a bagunça kkk Abraço!

Muito bom, obrigado por compartilhar.
As vezes tenho duvidas nos projetos de testes pois esses commits semanticos sao geralmente para projetos de desenvolvimento, será que para projetos de testes automatizados podemos seguir no mesmo caminho? Eu tento seguir nos projetos em que participo mas as vezes acho que deixo a galera meio bugada com o conceito.

Excelente, já tinha ouvido falar do feat, fix e refactor.
Apesar disso, nem sempre utilizo (Ainda irei adquirir esse hábito ).

Já os outros eu não tinha conhecimento.

Dicas valiosissimas, eh muito importante ter um padrao para documentar os commits. Muito obrigado pelo conteudo.

Manno muito massa!! Eu iniciante fzendo textão nos commits kkkkkk

Massa valeu

Caramba! Muito útil, mais uma prática que vou implementar no meu dia a dia

Já vou colocar isso no mural da minha sala ahahahah