This is an old version of this page. You can view the most recent version or browse the history.

Processo

🌱 Padrões de Branch e Commit

📌 Commits

Estamos utilizando o padrão Conventional Commits baseado em @commitlint/config-conventional.

Os commits devem seguir <tipo>(<escopo>): <mensagem>;
Escopo é a abreviação da user story com hífen e dois dígitos (e.g., us-01);
Mensagens de commit não podem ultrapassar 72 caracteres e devem ser escritas no imperativo;
Tipo é conforme abaixo:

🔹 Tipos de commit:

Tipo	Descrição
`feat`	Adição de uma nova funcionalidade
`fix`	Correção de um bug
`refactor`	Refatoração de código (sem mudanças na funcionalidade)
`chore`	Tarefas de manutenção (ex.: atualização de dependências)
`docs`	Alterações na documentação
`test`	Adição ou modificação de testes
`style`	Mudanças de formatação e estilo (sem afetar funcionalidade)

Exemplos:

feat(us-01): I did something
fix(no-ref): something case sensitive

🔹 Regras:

O tipo do commit deve estar em minúsculas.
O identificador da us deve estar entre parênteses.
A descrição deve ser breve e começar com letra minúscula.

📌 Branches

As branches para desenvolvimento devem ser feitas a partir da develop. Os nomes de branch devem seguir <tipo>/<escopo>/<descrição>, onde a descrição deve ser breve e com hífen no lugar dos espaços. Tipo e escopo são definidos conforme dito anteriormente.

Exemplos:

us-01/issue-naming
no-ref/writing-something-here

🔹 Regras:

us-XX/descricao → Para tarefas relacionadas a uma User Story (US). O número XX representa a ID da US.
no-ref/descricao → Para alterações sem uma US específica.
Utilize hífens (-) para separar palavras na descrição da branch.
A descrição deve ser curta e clara.

🚨 Merge Requests

O título do merge request deve seguir o mesmo formato dos commits acima. Os MRs precisam passar todos os jobs no pipeline e, após isso, podem ser mergeados por um AGES III. É obrigatório submeter o MR no formato definido pelo template.