A utilização do Git para versionamento de código é algo que faz parte do dia a dia de qualquer desenvolvedor de software, seja iniciante, estagiário, júnior, pleno ou sênior. De modo geral, o versionamento consiste em estratégias para gerenciar as diferentes versões de um código, de um sistema ou de um modelo. Então, os commits são formas de administrar as mudanças que são feitas e de garantir mais segurança na transição de uma versão para outra.

[adrotate banner=”4″]

Sendo assim, para poder otimizar o tempo de desenvolvimento de um projeto e entender em que ponto está esse desenvolvimento, os commits se fazem extremamente necessários. Por conta disso, eles precisam ser levados a sério e nomeados da melhor e mais clara maneira possível.

Assim, utilizar Padrões de Commits, também chamados de Conventional Commits ou Commits Semânticos, é uma excelente forma de melhorar os seus commits.

O que são commits e padrões de commits?

Os commits são basicamente o estado em que o projeto se encontra na linha do tempo. Ou seja, a versão do projeto naquele momento em que o commit foi criado.

Assim, os padrões de commits são uma série de convenções e boas práticas, que descrevem e dão uma boa noção para nomear as mensagens dos commits, de modo a deixá-los mais claros, bem estruturados e específicos. Em outras palavras, os padrões de commits auxiliam os desenvolvedores a nomear os commits para que eles digam exatamente qual foi a natureza da mudança e que mudança foi feita.

Vale ressaltar que essas regras, além de ajudar o desenvolvedor, irão também auxiliar o time, os novos membros da equipe, o público no geral, os clientes e todos os demais stakeholders. Isso porque, como todos os commits agora seguem uma regra específica e comunicam bem a natureza da sua alteração, todos conseguem entender exatamente o que aquela mudança faz, no que o time está trabalhando no
momento, em que estado se encontra o projeto, etc.

Como utilizar padrões de commits nos projetos?

Agora que já foi definido o que são commits semânticos, vamos entender como utilizá-lo na prática.

Basicamente, as regras são bem simples de compreender, como mostra o exemplo abaixo:

Essa estrutura requer um tipo (obrigatório) para indicar qual foi a natureza da mudança, um escopo ou contexto do commit (opcional), uma descrição (obrigatório) para informar qual foi a mudança feita, um corpo para descrições mais detalhadas (opcional) e um rodapé (opcional).

Então, neste artigo, abordaremos apenas os pontos obrigatórios e o escopo, que são os mais utilizados no dia a dia.

Tipos de commits

Para indicar bem qual foi a mudança realizada no projeto, é importante conhecer os tipos de commits que podem ser aplicados. Dessa forma, eles seguem as regras da tabela a seguir:

Tipo	Significado
feat	Indica que o trecho de código está incluindo um novo recurso (nova feature).
fix	Indica que o trecho de código está solucionando um erro que está causando bugs na aplicação.
docs	Indica que houveram mudanças na documentação.
test	Indica alterações em testes, seja criando, alterando ou excluindo testes unitários.
refactor	Indica mudanças devido a refatorações que não alteram sua funcionalidade.
build	Indica modificações em arquivos de build e/ou dependências.
chore	Indica atualizações de tarefas de build, configurações de administrador, pacotes, etc. Porém, diferente do tipo build, o chore são mudanças de desenvolvimento. Em outras palavras, mudanças que não afetam o sistema ou arquivos de testes.
perf	Indica quaisquer alterações de código que estejam relacionadas à performance.
style	Indica que houveram alterações referentes a formatação de código, mas que não alteram o sistema.
revert	Indica que houve uma reversão de um commit anterior.

Escopo de commits

O escopo de commit serve basicamente para contextualizar o commit, indicando quais pontos do sistema essa mudança irá afetar. Então, apesar de não ser obrigatório, o escopo é muito útil principalmente em projetos grandes, com diversas features e escopos diferentes.

Dessa forma, informar os impactos do trecho de código nos commits auxilia em todas as etapas de desenvolvimento do projeto.

Abaixo, segue um exemplo de utilização do escopo para informar a adição de uma nova feature que atualiza os dados do usuário.

Descrição do commit

A descrição precisa ser o mais curta, clara e objetiva possível. O recomendado é que ela inicie com algum verbo que indique a alteração e tenha entre 4 e 6 palavras (no máximo) que descreva o que – de fato – foi alterado no projeto.

Entretanto, para descrições mais detalhadas, tente manter o padrão de 4 a 6 palavras na primeira linha e utilize o corpo do commit para descrever em maiores detalhes o que foi alterado. Abaixo segue um exemplo para ilustrar melhor.

Então, o exemplo acima apresenta duas maneiras de nomear a adição de uma nova feature. Assim, ambas passam o mesmo significado. Porém, a primeira é mais clara e objetiva, enquanto a segunda apresenta mais informações que não são tão relevantes.

Conclusão

Utilizar os padrões de commits no dia a dia é, sem sombra de dúvidas, necessário. Principalmente em grandes projetos, em que existem inúmeras features que, com o passar do tempo, pode acabar ficando caótico navegar na linha do tempo dos commits.

Assim, utilizar o conjunto de regras apresentadas neste artigo permitirá que tanto desenvolvedores quanto todos os demais stakeholders consigam entender em que estado do desenvolvimento a aplicação se encontra, quais features já foram implementadas e em que escopo elas afetarão.

Dessa forma, quando for fazer um novo commit, lembre-se de aplicar essas regras.

Veja também:

Como Padronizar Códigos com Style Guides

Autor: Junior Vinicius Silva.

[adrotate banner=”5″]