Entendendo o Commit no GitHub: O que é o tal do "feat:" e como isso pode melhorar seu código!

Quem aí já se pegou subindo projetos para o GitHub pelo terminal e, na hora de fazer o commit, usava sempre feat: por repetição?

Eu confesso, essa era eu! Kkkkkk. Eu só ia na onda, sem nem lembrar mais por que usava isso, até que parei, questionei e descobri que estava classificando toda e qualquer atualização do meu projeto de forma equivocada. Se acontece de até com os melhores, quem dirá com nós que estamos começando, né?

Se você ainda não me conhece, prazer, sou a Miriã, estou em plena transição de carreira, cursando Análise e Desenvolvimento de Sistemas.

Através da DIO, tenho me dedicado ao desenvolvimento Front-End, aprendendo bastante sobre Angular. Sei que mudar de área pode ser um baita desafio, cheio de altos e baixos, né? Por isso, tô organizando minhas anotações com todo carinho pra ajudar quem também tá começando nessa jornada. Vamos descomplicar alguns conceitos juntos?

Hoje, quero compartilhar o que aprendi de um jeito que vai clarear tudo para você!

A gente costuma fazer o processo básico para subir as alterações:

git add .
git commit -m "feat: finge que alterei alguma coisa e descrevi brevemente"
git push origin main

Mas a mágica está na mensagem do commit! Vamos mergulhar?

A teoria por trás do "feat:" - Conventional Commits

O feat: que vemos na mensagem do commit não é um comando Git, e sim uma convenção de escrita de mensagens. Pense nele como uma etiqueta, um rótulo que ajuda a classificar o tipo de mudança que você fez no seu código.

Essa prática segue algo chamado Conventional Commits. Mas, Miriã, por que isso é importante?

A ideia por trás do Conventional Commits é padronizar as mensagens de commit. Isso traz muitas vantagens:

Leitura Facilitada: Seu histórico de commits se torna muito mais fácil de entender. Bateu o olho, sabe o que rolou!
Automação: Ferramentas podem usar esses "rótulos" para gerar automaticamente um CHANGELOG.md (aquele histórico de versões do seu projeto) ou até para decidir qual será o próximo número de versão do seu software.
Colaboração: Facilita a vida do seu time, que consegue entender rapidamente as alterações sem precisar perguntar a cada commit.

O formato básico de um commit convencional é bem simples:

<tipo>: <descrição-curta>

Agora que entendemos a base, vamos aos tipos mais comuns e como identificá-los.

Os tipos de Commit na prática, a receita do bolo do seu projeto!

Para te ajudar a associar e nunca mais esquecer, vamos fazer uma analogia que eu adoro, associada a comida kkkk! Pensa assim: Seu projeto é um bolo 🎂 e cada commit é uma etapa da receita!

feat: (de feature - nova funcionalidade)

No bolo: Você decidiu adicionar um novo sabor ao bolo, talvez uma cobertura de brigadeiro que não estava prevista! É algo novo e delicioso que expande a receita.
No código: Indica uma nova funcionalidade no código. É o tipo que você usaria para adicionar uma nova página, um novo componente, uma nova função ou qualquer recurso inédito.
Exemplo: feat: adicionar carrinho de compras

fix: (correção de bug)

No bolo: O bolo desandou um pouco, talvez o fermento não agiu direito. Você corrigiu um bug!
No código: Indica uma correção de bug. Você usa fix: quando conserta algo que estava quebrado ou não funcionando como esperado.
Exemplo: fix: corrigir erro de login que impedia acesso

docs: (documentação)

No bolo: Você fez uma anotação na receita para deixar mais clara, ou corrigiu um erro de português nas instruções.
No código: Indica mudanças na documentação (por exemplo, no arquivo README.md, nos comentários do código, ou em guias de uso).
Exemplo: docs: atualizar README com instruções de instalação

style: (estilo)

No bolo: Deixou a decoração do bolo mais bonita, trocou a cor da cobertura, mas o sabor é o mesmo.
No código: Indica mudanças que não afetam a lógica do código. Isso inclui formatação, espaços, ponto e vírgula, organização de linhas, etc. É sobre a "beleza" e legibilidade do código.
Exemplo: style: ajustar indentação e espaçamento do código

refactor: (refatoração)

No bolo: Você mudou a ordem dos ingredientes, ou o método de preparo, para que o bolo fique ainda melhor, mas o resultado final (o sabor) é o mesmo.
No código: Indica uma refatoração do código. Ou seja, você mudou a estrutura interna, melhorou a arquitetura ou a legibilidade, mas sem alterar a funcionalidade externa para o usuário.
Exemplo: refactor: otimizar função de cálculo de impostos

chore: (tarefas de manutenção)

No bolo: Você trocou a tigela por uma maior, ou comprou um batedor novo. Não é parte da receita do bolo em si, mas ajuda no processo.
No código: Indica mudanças em tarefas de build, configurações, ou outras ferramentas que não afetam o código-fonte principal. Como a configuração do .gitignore, atualização de dependências, ou ajustes nos scripts do projeto.
Exemplo: chore: atualizar dependências do projeto

Por que adotar o Conventional Commits?

Agora que você viu a receita, deve estar se perguntando: "Miriã, por que me preocupar tanto com isso?". A resposta é simples, organização e profissionalismo!

É como ter um armário super organizado, fica muito mais fácil encontrar o que precisa, manter a ordem e até saber o que está faltando!

As principais vantagens de usar essa convenção são:

1 - Histórico de Projeto Claro e Legível: bata o olho no git log (o histórico de commits) e você (e seu time!) saberá imediatamente o que cada commit fez. Adicionou uma funcionalidade? Corrigiu um bug? Mudou só a documentação? Fica tudo na cara! Isso economiza tempo e evita mal-entendidos.

2 - Facilita a Geração de CHANGELOG.md: muitas ferramentas podem usar os tipos dos seus commits para gerar automaticamente o CHANGELOG.md – aquele "diário de bordo" do seu projeto que lista todas as mudanças importantes entre as versões. Isso é super útil para manter os usuários e desenvolvedores informados sobre as novidades.

3 - Suporte à Automação de Versões: ferramentas específicas podem até mesmo usar os tipos de commit para determinar o próximo número de versão do seu projeto (semantic versioning). Por exemplo, um feat: pode indicar uma nova "versão menor" (Ex: de 1.0.0 para 1.1.0), enquanto um fix: pode indicar uma "versão de correção de bug" (Ex: de 1.0.0 para 1.0.1). Isso é automação pura!

4 - Melhora a Colaboração em Equipe: se você trabalha em equipe, essa convenção é um divisor de águas. Facilita a revisão de código, a identificação de problemas e a integração de novas funcionalidades, pois todos falam a mesma "língua dos commits".

Embora você não seja obrigado(a) a usar essa convenção em todos os seus projetos pessoais, é uma ótima prática que a maioria dos desenvolvedores profissionais adota. Para quem está começando, como nós, usar feat: e fix: já é um excelente começo para deixar o seu código com cara de profissional e mostrar que você se preocupa com a organização e qualidade!

Colocando em prática seu guia rápido para o GitHub!

Agora que você já dominou a teoria e os tipos de commit, vamos ao passo a passo prático para subir suas alterações para o GitHub, aplicando o que aprendemos:

Para atualizar seu repositório no GitHub, siga esses comandos no terminal:

1- Preparar os arquivos para salvar (git add .)

Antes de tudo, precisamos "avisar" ao Git quais arquivos você quer incluir no seu próximo salvamento.

Comando: git add .

Dica: O . (ponto) adiciona todos os arquivos modificados. Se quiser ser mais específico, pode substituir o . pelo nome do arquivo ou pasta (git add nome-do-arquivo.html).

2- Criar um ponto de salvamento (git commit -m "sua mensagem")

Este é o comando que "salva" suas alterações no histórico local do seu projeto. E é aqui que a convenção de commits brilha!

Comando: git commit -m "tipo: sua mensagem descritiva aqui"

Exemplo: Se você criou um novo componente de menu, seria: git commit -m "feat: criar componente de menu de navegação"

Lembrete Rápido das Etiquetas:

feat: Nova funcionalidade
fix: Correção de bug
docs: Mudanças na documentação
style: Formatação, estilos
refactor: Melhoria de código sem mudar a funcionalidade
chore: Manutenção (configurações, dependências)

3- Enviar os commits para o GitHub (git push origin main)

Depois de salvar localmente, o próximo passo é enviar essas alterações para o seu repositório remoto no GitHub, tornando-as acessíveis para você e para o mundo (ou para seu time!).

Comando: git push origin main

Explicação: origin é o apelido padrão para o seu repositório remoto, e main é o nome da sua branch principal (a linha do tempo de desenvolvimento principal do seu projeto).

Resumo dos comandos para guardar no bolso:

git add .
git commit -m "feat: sua mensagem descritiva aqui"
git push origin main

Faça a Diferença com Seu Código!

Dominar a arte dos commits é um passo gigante para qualquer desenvolvedor, especialmente para quem está começando. Não é só sobre digitar comandos, é sobre comunicação, organização e profissionalismo. Ao adotar essa prática, você não só melhora seus próprios projetos, mas também mostra sua dedicação e cuidado com o código.

Espero que este artigo tenha desmistificado o "feat:" e te ajude a subir seus projetos com muito mais confiança e clareza!

Eu também estou aprendendo, e fazer esse artigo me deu ainda mais clareza ao que estou aprendendo, então fica a dica se quiser colocar seus conhecimentos em ordem e de quebra ajudar quem está começando também.

Aprendeu outros comandos e diretivas uteis que não citei aqui? Não retenha conhecimento, compartilha conosco. Já te agradeço por isso!!

Vamos nos conectar:

Meu LinkedIn: https://www.linkedin.com/in/miriaamaralcs
Meu GitHub: https://github.com/miriaamaral