Skip to content
This repository has been archived by the owner on Oct 19, 2024. It is now read-only.

Latest commit

 

History

History
96 lines (58 loc) · 5.77 KB

CONTRIBUTING.md

File metadata and controls

96 lines (58 loc) · 5.77 KB

Welcome to the contributing guide

Confira abaixo algumas dicas, orientações e boas práticas a serem consideradas ao contribuir com o projeto.

Source-control branching model

O grupo escolheu trabalhar seguindo o branching model GitHub Flow.

Para mais informaçoes sobre o GitHub Flow, visite https://docs.github.com/en/get-started/using-github/github-flow

GitHub Flow

O GitHub Flow funciona, em palavras simples, da seguinte forma:

  1. O desenvolvedor cria uma branch, a partir da branch main;

  2. O desenvolvedor faz commits na branch criada no Passo 1;

  3. Qdo terminar, o desenvolvedor abre uma Pull Request da branch criada por ele no Passo 1 para branch main;

Ao abrir PR no Passo 3 o GitHub Actions executará os testes unitários (se houver) e fará a análise estática do código usando o SonarCloud. Se houverem problemas no código, como falta de testes unitários, bugs ou falhas de segurança por exemplo, o GitHub Actions impede a aprovação da PR até que o dev faça as devidas correções. image

  1. Qdo a Pull Request for aprovada pelo(s) demais membro(s) do grupo, o código na branch criada no Passo 1 será integrado com a branch main.

Se houver um pipeline de CI/CD configurado, após o merge com a main o código na main será compilado pelo GitHub Actions, uma imagem de container será gerada e um deploy será realizado em produção.

Boas Práticas

Boas práticas para nomes de branches

Ao criar novas branches, procure seguir o seguinte padrão:

category/reference/title-in-trello

🛈 category pode ser feature, bugfix, hotfix ou test.

🛈 reference deve conter o número do card no Trello. Vide exemplo abaixo.

image

Use no-ref para atividades que não possuem card no Trello. Por exemplo feature/no-ref/atualizar-dependencias.

🛈 title-in-trello deve ser uma descrição curta da tarefa, sem espaços, separado por hífens, por exemplo "cadastro-cliente", "listar-pedidos" ou "criar-produto" de acordo com o título do card no Trello.

Exemplo completo: feature/16/context-map

Para mais informações sobre boas práticas para nomes de branches visite o artigo Git Branch Naming Convention no dev.to

Boas práticas para mensagens de commits

Conventional Commits

Procure seguir a especificação Conventional Commits disponível em https://www.conventionalcommits.org/pt-br/v1.0.0/

Ao fazer commits, procure seguir o seguinte padrão:

type(scope): Description goes here

🛈 type pode ser feat, fix, build, chore, ci, docs, style, refactor, perf ou test.
Para consultar o significado de cada type visite https://blog.rocketseat.com.br/como-fazer-um-commit-conventional-commits/#tipos

🛈 scope (OPCIONAL) deve conter o número do card no Trello. Vide exemplo abaixo.

image

Caso a atividade não possua card no Trello, basta omitir o (scope). Por exemplo docs: Cria o Context Map.

🛈 Description deve conter uma descrição curta do que foi feito no commit, pode conter espaços, por exemplo "Cadastro do cliente", "Cria o Domain Story digitalizado" ou "Corrige o cadastro de produtos".

Exemplo completo: feature(6): Cadastro do cliente

Atenção!

⚠️ As mensagens de commit devem seguir preferencialmente a famosa Regra dos 50/72 ou seja: A parte da description deve conter no máximo 50 caracteres e a mensagem de commit completa incluindo o type e o scope deve conter no máximo 72 caracteres.
⚠️ Os verbos devem estar sempre no Modo Imperativo! Por exemplo, usar a palavra "Cria" ao invés de "Criar", "Criando" ou "Criado".

Para mais informações sobre conventional commits, visite:
https://blog.rocketseat.com.br/como-fazer-um-commit-conventional-commits/
https://www.conventionalcommits.org/

Commits Atômicos

Procure fazer commits atômicos, ou seja, "O menor possível, mas completo".

Algumas das vantagens dos commits atômicos são:

  1. Facilidade para fazer revert no futuro caso por algum motivo seja necessário;
  2. O histórico do Git fica mais limpo;
  3. As Pull Requests ficam mais fáceis de revisar;
  4. Divide um trabalho grande em passos menores.

Para mais informações sobre commits atômicos visite o artigo How atomic Git commits dramatically increased my productivity - and will increase yours too no dev.to

Dicas

Você pode usar o comando squash do Git para unificar um ou mais commits em um único commit. Para mais informações, visite https://www.git-tower.com/learn/git/faq/git-squash