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

Latest commit

 

History

History
106 lines (65 loc) · 6.94 KB

CONTRIBUTING.md

File metadata and controls

106 lines (65 loc) · 6.94 KB
Raw

Welcome to the contributing guide

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

Source-control branching model

Após votação realizada no Discord, o grupo escolheu trabalhar seguindo o modelo de controle de versão "Trunk-based development", o mesmo modelo adotado pelo Google.

Trunk-Based Development

O Trunk-based development funciona, em palavras simples, da seguinte forma:

  1. O dev cria uma branch pra ele trabalhar, a partir da branch main

  2. O dev faz commits na branch criada no Passo 1

  3. Qdo terminar, o dev abre uma Pull Request da branch que ele criou no Passo 1 para branch main

  4. [OPCIONAL] Após a abertura da PR no Passo 3 o GitHub Actions executa os testes unitários (se houver) e faz a análise estática do código que o dev criou, usando o SonarCloud (print screen abaixo). Se houver problemas no código, como bugs ou falhas de segurança por exemplo, o GitHub Actions impede a aprovação da PR aberta no Passo 3 até que o dev faça as devidas correções

image

  1. Qdo a PR for aprovada pelo(s) demais membro(s) do grupo, o código que o dev fez na branch criada no Passo 1 vai para a branch main

  2. [OPCIONAL] 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, no Kubernetes ou no ECS da AWS

Dúvidas sobre o Trunk-based development

Estou trabalhando em uma feature muito grande que vai levar vários dias para ser finalizada. Como lidar com esse cenário na Trunk-based development?

Resposta: De acordo com a Trunk-based development você pode utilizar Feature Flags para manter desativada novas funcionalidades incompletas que ainda estão em desenvolvimento, até que elas estejam prontas para serem habilitadas em produção.
Fonte: https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development#:~:text=Feature%20flags%20nicely%20complement%20trunk%2Dbased%20development%20by%20enabling%20developers%20to%20wrap%20new%20changes%20in%20an%20inactive%20code%20path%20and%20activate%20it%20at%20a%20later%20time.

Para mais informações sobre o Trunk-based development visite https://cursos.alura.com.br/extra/alura-mais/git-flow-versus-trunk-based-development-c1401

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

Dica

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