Pular para o conteúdo principal

Padrões Utilizados no Git

Este documento tem como objetivo apresentar os padrões de desenvolvimento utilizados pelas equipes de desenvolvimento.

Versionamento​

O versionamento é feito utilizando o SemVer, que é um padrão de versionamento de software que visa facilitar a gestão de versões de software. O SemVer é composto por três partes: MAJOR.MINOR.PATCH, onde:

  • MAJOR: quando você fizer alterações incompatíveis na API pública;
  • MINOR: quando você adicionar funcionalidades mantendo compatibilidade;
  • PATCH: quando você corrigir bugs mantendo compatibilidade.

Além disso, o SemVer também permite adicionar rótulos adicionais para identificar versões pré-lançamento e metadados de compilação, que são separados pelo caractere hífen (-). Por exemplo, 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-rc.7, 1.0.0-beta.4.

Commits​

Os commits devem ser feitos utilizando o padrão Conventional Commits, que é um padrão de mensagem de commit que tem como objetivo tornar a criação de histórico de commits mais fácil e padronizada.

Utilizando o padrão Conventional Commits, as mensagens de commit devem seguir o seguinte formato: <tipo>: <mensagem>, onde:

  • tipo: é o tipo da mensagem de commit, que pode ser um dos seguintes:
    • feat: nova funcionalidade;
    • fix: correção de bug;
    • style: alteração de layout, sem alterar funcionalidade;
    • refactor: alteração/melhoria de fonte;
    • perf: alteração que afeta o desempenho;
    • test: adição de testes ausentes ou correção de testes existentes.
    • chore: alteração que não afeta o código-fonte ou os testes (ex.: atualização de dependências, etc);
    • ci: alteração no script e workflow para configuração e execução de CI;
  • mensagem: é a mensagem de commit que descreve as alterações feitas.

Exemplo de commit​

feat: validação de chaves pix do tipo e-mail

Pull Requests​

Os pull requests devem ser feitos e nomeados seguindo os padrões de versionamento e commits descritos acima, além de conter uma descrição detalhada das alterações feitas e o motivo delas. A descrição deve ser feita utilizando o formato Markdown.

Exemplo de pull request​

Título

feat: validação de chaves pix do tipo e-mail

Descrição:

### Descrição

Validação de chaves pix do tipo e-mail. Forçando o usuário a informar o código enviado por e-mail para confirmar que a chave é realmente dele.

### Motivo

Usuários estavam podendo informar qualquer e-mail para cadastrar uma chave pix do tipo e-mail, o que não é permitido pela API do Banco Central.

Branches​

As branches devem ser nomeadas utilizando o padrão Kebab Case, que é um padrão de escrita de palavras compostas em que as palavras são separadas por hífens (-).

São compostas por três partes: <TIPO>/<ID LINEAR>-<DESCRICAO>, onde <TIPO> é o tipo da branch, que segue os mesmos tipos de commit, e <ISSUE> é o código da tarefa no Linear.

Exemplo de Branch​

feat/onz-311-suporte-arquivos-json