Como fazer um COMMIT padronizado

Commits padronizados servem para ajudar você e sua equipe a entender melhor o que foi feito no desenvolvimento

Texto de Gustavo Henrique da Silva,

Application Development Analyst na Accenture

Já precisou entrar no seu github para procurar noscommits qualquer alteração que tenha feito e se deparou com algo mais ou menos assim?

No início eu não sabia que existiam boas práticas para escrever um commit, então acabava escrevendo desse jeito: “Start”, “Melhorias” e “Update”. Sempre que precisava buscar algo, ficava perdido, sem achar as alterações que queria. Isso aconteceu até eu descobrir o Conventional Commits.

O que é Conventional Commits?

Conventional commits é um padrão de escrita de mensagens de commit que segue uma estrutura específica para facilitar a geração de changelogs automatizados, melhorar a comunicação entre desenvolvedores e ajudar a manter o histórico do repositório organizado.

Esse padrão está alinhado com o semver (semantic versioning), descrevendo recursos (features), correções (fixes) e alterações (changes) efetuadas nos commits. Entre os benefícios desse padrão, podemos citar:

Criação automatizada de CHANGELOGs

Histórico estruturado

Facilita a criação de relatórios

Facilita a entrada de novos desenvolvedores

Facilita a comunicação entre os desenvolvedores

Como usar o padrão

O padrão é baseado em um prefixo específico (tipo), um escopo opcional, um espaço em branco, uma mensagem curta, uma descrição detalhada opcional e um rodapé, ficando da seguinte forma:

TIPO: [DESCRIÇÃO_DO_COMMIT]

[

CORPO_DO_COMMIT

]

[RODAPE_DO_COMMIT}

Tipos

Os prefixos em "Conventional Commits" são labels utilizadas para identificar o tipo de mudança feita em um commit. O objetivo dos prefixos é fornecer uma maneira padronizada de identificar o tipo de mudança em um repositório, o que pode ser útil para equipes de desenvolvimento de software. Aqui você pode conferir alguns dos tipos existentes:

Feat

Cria um novo recurso no código.

Fix

Corrige um bug no código.

Style

Mudanças que não afetam o significado do código (espaço em branco, formatação falta de ponto-e-vírgula, etc).

Refactor

Uma alteração que não corrige um bug, nem adiciona um novo recurso.

Test

Adicionando testes ausentes ou corrigindo testes existentes.

Docs

Apenas a documentação.

Chore

Alterações no processo de compilação ou ferramentas e bibliotecas auxiliares, como geração de documentação.

Perf

Mudança de Código que melhora performance.

Build

Alterações que afetam o sistema de compilação ou dependências externas (npm, gulp, broccoli).

Alterações em nossos arquivos e scripts de configuração de CI (Travis, Circle, github actions).

Exemplo:

feat

Escopo

O escopo do commit é uma parte opcional, curta e de fácil compreensão. É nela que iremos dizer qual parte do código foi modificada e como indicar que fizemos alterações apenas na camada de Client de um serviço.

Exemplo:

feat(usuario):

Descrição

A descrição, juntamente com o tipo, é uma das partes mais importantes do padrão: é aqui que deve ser descrito, de maneira clara, sucinta e simplificada, o que foi realizado no commit. É recomendado que essa parte tenha, no máximo, 70 caracteres, para que não se estenda muito.

Exemplo:

feat(usuario): criação da tela de login

Corpo

O corpo é a parte da mensagem de commit que fornece detalhes adicionais sobre as alterações feitas no código. Ele é opcional, mas é recomendado, especialmente quando as alterações são complexas ou precisam de contexto adicional. O corpo do commit deve ser escrito em uma ou mais linhas e deve fornecer informações suficientes para que outros desenvolvedores possam entender o que foi mudado e por quê.

A descrição curta e o corpo do commit, juntos, formam a mensagem de commit completa.

Exemplo:


feat(usuario): criação da tela de login
- criação da tela
- validação do e-mail
- validação da senha

Rodapé

O rodapé também é uma parte opcional da mensagem de commit que pode ser usado para fornecer informações adicionais sobre as alterações feitas no código. Ele geralmente é colocado após o corpo da mensagem e é separado do corpo por uma linha em branco. O rodapé do commit pode ser usado para incluir informações como números de ticket de suporte, links para relatórios de bugs ou outros recursos relacionados.

Exemplo:


feat(usuario): criação da tela de login
- criação da tela
- validação do e-mail
validação da senha
Closes #123

Como praticar

Para facilitar a aplicação desse padrão existem ferramentas que podem te auxiliar bastante.

Husky

Cria um Hook para validar o commit com o CommitLint.

CommitLint

Tem como objetivo ajudar você e seu time a aderir o padrão convencional de commits validando o commit quando ele é efetuado.

Commitzen

Ajudar a escrever o commit com todas as informações necessárias, te ajudando a não esquecer nada.

Às vezes é um pouco chato instalar e configurar ferramentas. Por isso, criei um script que pode ser usado para criar o projeto do zero e configurar as três ferramentas.


Requisitos para executar o script:
Ter YARN instalado
Básico de Shel Script

Observação: o Yarn pode ser substituídos por NPM

Aqui você vai encontrar o script criado para configurar um repositório do zero com as ferramentas que comentei acima, assim você só vai precisar se preocupar em executar o comando.

Se você quiser saber um pouco mais, pode acessar as documentações utilizadas aqui: