[PT-BR] Git Commit Patterns
Tags: git, beginners, productivity, braziliandevs
Published: 2023-01-27 16:00:00

O uso do Git para nós Devs é algo essencial, seja em projetos pessoais, de código aberto com muitas pessoas ou uma comunidade.
Dado isso, é importante utilizarmos o **git commit** apropriadamente. Termos uma linguagem coerente e padronizada ajuda a todos os envolvidos no projeto a entenderem as mudanças ocorridas.

![Bad Commit Timeline](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7r0qv3vii7v7yjxyxef2.png)

Na imagem acima, percebemos o quão prejudicial podem ser commits mal comentados, uma vez que não conseguimos entender a natureza da mudança ocorrida e o contexto que se aplica. A longo prazo, o efeito é ainda mais danoso, dado que a manutenibilidade do software é prejudicada devido a incoerência no escopo dessas mudanças, e como afetaram o projeto no passado.
Diante disso, vamos falar um pouco sobre o **Conventional Commits Pattern**.

---

###O que é ?

O [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) é uma convenção simples de mensagens de commit, que segue um conjunto de regras e que ajuda os projetos a terem um histórico de commit explícito e bem estruturado.

---

###Como utilizar

As regras são muito simples, como demonstrado abaixo temos um tipo de _commit (type)_, o escopo/contexto do _commit (scope)_ e o assunto/mensagem do _commit (subject)_.

```
!type(?scope): !subject
<?body>
<?footer>
```

Dessa maneira, `!` indica os atributos obrigatórios e `?` indica os atributos não obrigatórios.

---

###Subject: Imperativo ao invés de pretérito (modo passado)

Desse modo nós estamos dizendo à nossa equipe **o que fará o commit se aplicado**.

![Commit Subject use](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mfm2chjhctjdspyfl4t8.jpg)

“**If applied, this commit will change the markup**”, o que faz mais sentido do que: “_If applied, this commit will changed the markup_”

---

###Type: Quais são os tipos de commit

O **type** é responsável por nos dizer qual o tipo de alteração ou iteração está sendo feita, das regras da convenção, temos os seguintes tipos:

- `test`: indica qualquer tipo de criação ou alteração de códigos de teste. 
**Exemplo:** Criação de testes unitários.

- `feat`: indica o desenvolvimento de uma nova feature no projeto. 
**Exemplo:** Acréscimo de um serviço, funcionalidade, etc.

- `refactor`: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. 
**Exemplo:** Mudanças após um code review

- `style`: empregado quando há mudanças de formatação e estilo do código que **não alteram** o sistema de nenhuma forma.
**Exemplo:** Mudar o *style-guide*, mudar de convenção *lint*, arrumar indentações, remover espaços em brancos, remover comentários, etc..

- `fix`: utilizado quando há correção de erros que estão gerando bugs no sistema.
**Exemplo:** Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.

- `chore`: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento.
**Exemplo:** Mudar regras do *eslint*, adicionar *prettier*, adicionar mais extensões de arquivos ao .*gitignore*

- `docs`: usado quando há mudanças na documentação do projeto.
**Exemplo:** adicionar informações na documentação da API, mudar o *README*, etc.

- `build`: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas.
**Exemplo:** adicionar/remover dependências do *npm*, etc...

- `perf`: indica uma alteração que melhorou a performance do sistema.
**Exemplo:** alterar *ForEach* por *while*

- `ci`: utilizada para mudanças nos arquivos de configuração de CI.
**Exemplo:** *Circle*, *Travis*, *BrowserStack*, etc.

- `revert`: indica a reversão de um *commit* anterior.


![Commit Types use](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eu75nl5bcy3l4em3s87m.jpg)

_Observações:_

- Só pode ser utilizado um *type* por *commit;*

- O *type* é **obrigatório;**

- Caso esteja indeciso sobre qual *type* usar, provavelmente trata-se de uma grande mudança e é possível separar esse *commit* em dois ou mais *commits;*

- A diferença entre `build` e `chore` pode ser um tanto quanto sutil e pode gerar confusão, por isso devemos ficar atentos quanto ao tipo correto. No caso do Node.js por exemplo, podemos pensar que quando há uma adição/alteração de certa dependência de desenvolvimento presente em `devDependencies,` utilizamos o `chore.` Já para alterações/adições de dependências comuns aos projeto, e que haja impacto direto e real sobre o sistema, utilizamos o `build`.

---

###Scope: contextualizando o commit

Nesse ponto — e seguindo as convenções passadas — conseguimos entender o _tipo_ de alteração que foi realizada no _commit (commit type)_ e entender com clareza o que o commit irá trazer se aplicado _(commit subject)_.

Mesmo o scope **não sendo obrigatório**, ele pode ser utilizado para contextualizar o _commit_ e trazer menos responsabilidade para a _subject_, fazendo com que ele seja mais breve e conciso possível. **Lembrando que o _scope_ deve ser inserido no commit entre parênteses**.


![Commit Scope use](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mfiv8rrjrf40zsupe1w6.jpg)

_Observação:_ Os escopos devem ser separados com `/`

#### Conclusão

Escrevi este artigo no intuito de registrar um dos meus aprendizado meu _(eram só umas notas no notion)_, mas espero que possa ajudar outros desenvolvedores por ai.