Veja nesse artigo algumas das boas práticas que você pode utilizar na hora de dar os seus commits

A ideia deste post é ser algo rápido e claro que possa te ajudar na hora de enviar os seus commits.

Para iniciar eu gostaria de te fazer duas perguntas :

• Nos últimos dias você ou algum integrante do seu time enviou um commit parecido com: “subindo a ultima versão do código”, “agora vai” ou simplesmente enviou “m” ?
• Você já precisou analisar o histórico dos seus últimos commits e teve que entrar um por um porque não estava conseguindo entender a finalidade de cada um dos commits ?

Caso você tenha respondido sim para um destas perguntas, você e seu time precisam melhorar o padrão dos seus commits e para te ajudar, estou escrevendo este post rápido.

Primeiramente, os seus commits precisam responder as seguintes perguntas:

• Por que essa mudança é necessária? A mesma pode corrigir um bug, adicionar uma feature, melhorar a performance ou a segurança.
• Como a mesma resolve o problema? Para mudanças pequenas e óbvias essa parte pode ser omitida, mas a mesma consiste em uma descrição de alto nível de qual foi a abordagem usada para tratar o determinado problema.
• Quais os efeitos essas mudanças tem? Além das óbvias, isso pode incluir benchmarks, efeitos colaterais, etc.

Depois de responder as perguntas acima, você pode utilizar as boas práticas para criação de Commits semânticos. A seguir você tem algumas delas com uma breve descrição:

Feat: Utilizamos quando vamos criar uma nova feature no projeto. Ex.: estamos criando um novo endpoint em uma API ou estamos adicionando um novo service dentro do nosso projeto.

Refactor: Embora o nome sejá sugestivo, é bem importante reforçar a sua importancia. Utilizamos refactor quando estamos atualizando alguma parte do nosso código.

Hot Fix: Esse é um que nós temos receio de utilizar, mas que acabamos utilizando por conta da correria. Utilizamos o fix para subir alguma correção. Geralmente algum bug que precisamso corrigir e subir rápido em produção.

Chore: Utilizamos o chore quando fazemos alguma alteração que não influencia o nosso sistema nem algum dos nossos testes. Para ficar mais claro, utilizamos o chore para alterações como: adicionar algo dentro do .gitignore, isso não afeta o nosso sistema correto? Ou mudança no eslint que seria apenas uma config.

Style: O Style é utilizado para mudanças de formatação ou estilo de código que não influenciam na lógica do sistema.

Build: Esse nós utilizamos quando fazemos alguma mudança no build do nosso projeto.

Test: Como o próprio nome diz, o teste seria quando nós fazemos alguma alteração em algum teste do nosso projeto.

Perf: Esse é pouco conhecido, o pessoal acaba utilizando o Fix no lugar dele, pois utilizamos o perf quando fazemos alguma alteração na performance do nosso projeto como: melhora na performance de uma função ou query.

Docs: Esse acaba entrando no pacote de alterações do Chore por não alterar nada ou Style, mas podemos utilizar o Docs quando nós fazemos alguma alteração em algum arquivo de documentação como no swagger, readme…etc.

Bem simples né ? e acredite, utilizar essas boas práticas ajuda muito no nosso dia-a-dia 🙂

Bom era isso pessoal, espero que tenham gostado e até um próximo artigo 🙂