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 etcfeat: 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
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!
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 :+1:
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!
Nossa, massa demais! alguns desses eu não utilizava, mas faz todo sentido.
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!
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.
eu pensei em fazer isso tantas vezes. obrigado por ter feito!!!
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)
Ó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?
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.
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
Já vou colocar isso no mural da minha sala ahahahah