🎯 Deixe Seus Commits Super Poderosos com Conventional Commits 🚀
Imagina que você está construindo um projeto junto com várias pessoas e, de repente, você precisa entender o que todo mundo fez até agora. Aí, você olha os commits (as mensagens que a galera deixou ao salvar uma mudança no código) e encontra algo assim 🤯:
- "Corrigido bug."
- "Arrumei."
- "Melhorando a parada."
- "Finalizado."
Confuso, né? 🤔 O que foi arrumado? Qual bug? O que foi melhorado? É aqui que entra o Conventional Commits, uma forma de deixar tudo mais claro e organizado. Basicamente, é um conjunto de regrinhas que todo mundo segue para escrever essas mensagens de uma forma que faça sentido pra qualquer pessoa que abrir o histórico do projeto.
O Que é o Conventional Commits?
É como dar uma "receitinha" de bolo 🍰 para escrever mensagens de commit. Ao invés de jogar um "corrigido bug" no histórico, você vai escrever algo como:
fix(login): corrigido bug que impedia autenticação
Parece simples, né? E é mesmo! Vamos destrinchar essa mensagem:
- fix: aqui você diz que foi uma correção de bug. Se fosse uma nova funcionalidade, seria feat.
- login: é o escopo da mudança, ou seja, em qual parte do projeto você mexeu.
- corrigir bug que impedia autenticação : essa é a descrição, explicando de forma clara o que foi feito.
Como Usar?
Funciona assim: sempre que você for salvar uma mudança no código, segue o formato:
<tipo>(<parte do projeto>): <o que foi feito>
Aqui vão alguns exemplos:
- feat(pagamento): adicionaDO suporte a boleto bancário
- fix(navbar): corrigiDO bug de navegação no mobile
- chore(deps): atualizado dependências do projeto
Cada um desses commits fala exatamente o que foi feito, sem rodeios.
Principais Tipos de Conventional Commits 🎯
1. feat: ✨
• O que é?: Quando você adiciona uma nova funcionalidade ao projeto.
• Exemplo: feat(login): adicionar autenticação por Google
• Quando usar?: Sempre que criar algo novo que agrega valor ao projeto, como uma nova página ou funcionalidade.
2. fix: 🐛
• O que é?: Usado para corrigir bugs no código.
• Exemplo: fix(carrinho): corrigir erro ao adicionar item
• Quando usar?: Quando você corrige algo que estava quebrando ou funcionando errado no sistema.
3. docs: 📝
• O que é?: Para mudanças na documentação, como README, arquivos de comentários, etc.
• Exemplo: docs(README): adicionar instruções de instalação
• Quando usar?: Quando a mudança afeta somente a documentação, sem alterar o código.
4. style: 💅
• O que é?: Usado para mudanças de formatação, como indentação, espaço em branco, etc., que não afetam o funcionamento do código.
• Exemplo: style(css): ajustar espaçamento no layout
• Quando usar?: Quando você altera o visual ou o estilo do código sem mudar a lógica.
5. refactor: ♻️
• O que é?: Refatorações no código que não mudam o comportamento, mas melhoram a estrutura ou legibilidade.
• Exemplo: refactor(user): otimizar lógica de autenticação
• Quando usar?: Quando você melhora o código sem alterar o que ele faz, como trocar um loop por uma função mais eficiente.
6. test: 🧪
• O que é?: Usado para adicionar ou corrigir testes no projeto.
• Exemplo: test(profile): adicionar testes unitários para validação
• Quando usar?: Sempre que criar ou melhorar testes automatizados.
7. chore: 🛠️
• O que é?: Para tarefas de manutenção, como atualizações de bibliotecas ou mudanças menores que não afetam o código de produção.
• Exemplo: chore(deps): atualizar versão do React
• Quando usar?: Quando você faz algo nos bastidores, como atualizações de dependências, configuração de ferramentas, etc.
8. perf: ⚡
• O que é?: Para melhorar a performance do código.
• Exemplo: perf(api): otimizar consulta ao banco de dados
• Quando usar?: Quando você altera algo para o código rodar mais rápido ou consumir menos recursos.
9. build: 🏗️
• O que é?: Usado para mudanças que afetam o processo de build ou dependências externas, como configurações do npm, webpack, etc.
• Exemplo: build(grunt): adicionar task de minificação de CSS
• Quando usar?: Quando alterar algo que afete como o projeto é construído ou empacotado.
10. ci: 🤖
• O que é?: Para mudanças no sistema de integração contínua (CI), como configurações de pipelines.
• Exemplo: ci(travis): corrigir script de build
• Quando usar?: Quando fizer ajustes no CI, como configuração de scripts de automação para testes ou deploy.
Resumo dos Principais Commits 🔥
• feat: Nova funcionalidade.
• fix: Correção de bug.
• docs: Alterações na documentação.
• style: Mudanças de estilo (sem impacto na lógica).
• refactor: Melhorias no código sem alterar o comportamento.
• test: Adição ou correção de testes.
• chore: Tarefas de manutenção ou atualizações de dependências.
• perf: Otimizações de performance.
• build: Mudanças no sistema de build ou dependências externas.
• ci: Alterações no sistema de integração contínua.
Por Que Usar Conventional Commits?
1.Clareza Total: Com mensagens claras e padronizadas, todo mundo sabe exatamente o que cada commit fez. Isso facilita a vida de quem está revisando o código ou tentando entender uma mudança antiga.
Exemplo: Você vai revisar o código e, ao invés de ver um monte de "arrumei tal coisa", você vê "fix(carrinho): corrigido erro ao remover produto". Fica bem mais fácil, né? 😌
2. Automação: Ferramentas de automação amam essa padronização 🤖. Por exemplo, dá pra gerar automaticamente um *changelog* (uma lista do que mudou entre versões) e até controlar as versões do projeto com base nos tipos de *commits* (ex: se tem um **feat**, pode aumentar a versão).
3. Organização: O projeto fica com uma carinha mais profissional 🏆. Quando todo mundo segue a mesma regra, fica mais simples e rápido entender o que está rolando no código.
E Por Que Commits em Inglês? 🇬🇧
Eu sei, pode dar uma preguiça fazer as mensagens em inglês, mas tem bons motivos pra isso:
1. Comunidade Global: Se algum dia seu projeto for aberto ao mundo 🌍, ou se alguém de fora da sua equipe precisar olhar o código, eles vão entender o que está acontecendo. Inglês é a língua padrão da programação, então é bom adotar.
2. Padrão do Mercado: Muitas empresas grandes já utilizam o inglês como padrão, principalmente aquelas que trabalham com equipes internacionais. Então, se você quer estar preparado pra entrar numa dessas, melhor ir se acostumando! 💼
3. Consistência: Misturar português com inglês (tipo, código em inglês e *commits* em português) pode deixar o projeto meio bagunçado. Fazer tudo em inglês dá aquela sensação de uniformidade e organização 🎯.
Resumindo...
O Conventional Commits é tipo aquele manual de boas práticas 📜 que vai deixar seus commits mais organizados, claros e prontos para qualquer pessoa entender. E o melhor: você também pode automatizar um monte de coisas no seu projeto, como gerar logs de mudança e gerenciar versões de forma inteligente 💡.
Então, na próxima vez que for salvar algo no seu projeto, nada de "consertado bug" ou "mexi naquilo". Pensa no que foi feito e use algo como:
fix(cadastro): corrigido validação de e-mail
E, claro, aproveita pra treinar o inglês! Isso vai te abrir portas 🚪 e deixar seu projeto preparado pra qualquer pessoa, de qualquer lugar do mundo, entender tudinho o que está rolando. 🌎
