🎯 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. 🌎