Convencionando Devs:

Um commit atômico é um commit que tem apenas um objetivo (corrigir, implementar ou refazer algo), que está 100% pronto e que todos os seus arquivos estejam dentro do mesmo contexto.

• Resumir em poucas palavras;
• Não deve ser algo que está quebrando (ou não deveria quebrar);
• Se estiver mudando arquivos diferentes por motivos diferentes, o ideal é que eles sejam estejam em commits diferentes;
• Feito 2 alterações no mesmo arquivo por motivos diferentes, também devem estar em commits diferentes.

fix: um commit do tipo fix soluciona um problema na sua base de código.

feat: um commit do tipo feat inclui um novo recurso na sua base de código.

BREAKING CHANGE: inclui uma modificação que quebra a compatibilidade da API. Uma BREAKING CHANGE pode fazer parte de commits de qualquer tipo.

Outros: tipos adicionais são permitidos além de fix: e feat:, por exemplo @commitlint/config-conventional (baseado na Convenção do Angular) recomenda-se chore:, docs:, style:, refactor:, perf:, test:, entre outros.

• feat: Nova funcionalidade
• fix: Correção de bug
• docs: Mudanças na documentação
• style: Formatação de código, não afeta o funcionamento
• refactor: Refatoração de código, sem novas funcionalidades ou correções de bugs

• Formato (Regras 2, 5, 6 e 7):

  Os softwares que utilizam versionamento semântico utilizam um padrão numérico dividido em três posições, como no exemplo: 5.8.15.

• Major

  São as chamadas breaking changes, atualizações que possuem o potencial de “quebrar” códigos que utilizam versões anteriores.

  4.x.x → 5.x.x

• Minor

  O segundo dígito informa a versão da funcionalidade, onde uma nova função ou melhoria substancial é adicionada e não há problemas de incompatibilidade com outras versões.

  5.1.x → 5.2.x

• Patch

  O terceiro dígito informa a versão da correção de bugs, melhorias de desempenho ou alterações similares que não alteram as funcionalidades atuais e nem introduzem novas.

  5.2.0 → 5.2.1

Existem 12 regras que definem o SemVer e elas estão documentadas oficialmente em: https://semver.org/lang/pt-BR/. Mas também há esse artigo no iMasters muito bem explicativo: https://imasters.com.br/codigo/versionamento-semantico-o-que-e-e-como-usar.

Um changelog é um arquivo que contém uma lista selecionada, ordenada cronologicamente, de mudanças significativas para cada versão de um projeto.

• Changelogs são feitos para pessoas, não para máquinas.
• Cada versão deve ter sua própria entrada.
• Agrupe as alterações por tipo.
• Permita que versões e seções possam ser vinculadas com links.
• A versão mais recente deve sempre aparecer primeiro.
• Inclua a data de lançamento de cada versão.
• Indique se você segue o versionamento semântico.