| ... | ... | @@ -26,8 +26,11 @@ Esta seção é dedicada a apresentar o processo de desenvolvimento do time, jun |
|
|
|
- [xxx](#git-workflow)
|
|
|
|
- [xxx](#code-freezing)
|
|
|
|
- [Definition of Ready](#definition-of-ready)
|
|
|
|
- [Padrões utilizados](#padrões-utilizados)
|
|
|
|
- [Definition of Done](#definition-of-done)
|
|
|
|
- [Padrões utilizados](#padrões-utilizados)
|
|
|
|
- [Branches](#branches)
|
|
|
|
- [Commits](#commits)
|
|
|
|
- [Merge Requests](#merge-requests)
|
|
|
|
|
|
|
|
---
|
|
|
|
|
| ... | ... | @@ -49,13 +52,13 @@ Para que uma tarefa seja considerada concluída ela deve seguir as seguintes con |
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
### Padrões utilizados
|
|
|
|
# Padrões utilizados
|
|
|
|
|
|
|
|
#### Idioma padrão:
|
|
|
|
#### Idioma padrão
|
|
|
|
|
|
|
|
Como acordo, todas as branches, commits e MR devem ser descritos em inglês.
|
|
|
|
|
|
|
|
#### Branches
|
|
|
|
### Branches
|
|
|
|
|
|
|
|
|
|
|
|
Para criar uma branch e começar a trabalhar nela, 3 comandos git serão essenciais, vejamos abaixo quais são eles:
|
| ... | ... | @@ -75,7 +78,7 @@ Exemplos: |
|
|
|
- ```build/12```
|
|
|
|
- ```spike/11```
|
|
|
|
|
|
|
|
**Excessões**
|
|
|
|
**Exceções**
|
|
|
|
|
|
|
|
Caso a demanda que está sendo desenvolvida não esteja descrita em uma task em nosso board do Trello, devemos seguir o seguinte padrão:
|
|
|
|
|
| ... | ... | @@ -85,7 +88,7 @@ Ser o mais sucinto possível no nome da branch, caso necessite seja mais descrit |
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
#### Commits
|
|
|
|
## Commits
|
|
|
|
|
|
|
|
Para tornar mais consistentes as mensagens de commit, usamos o padrão Conventional Commits. Para seguir esse padrão, as mensagens, em geral, devem escritas seguindo no formato `<tipo>[escopo]: <descrição>`, em que:
|
|
|
|
- o `<tipo>`, obrigatório, é um dos tipos possíveis de commit;
|
| ... | ... | @@ -108,7 +111,7 @@ Tipos usados no time: |
|
|
|
- "`docs`", para identificar trabalho na documentação do projeto;
|
|
|
|
- "`build`", para identificar trabalho na configuração do projeto.
|
|
|
|
|
|
|
|
Mais informações estão disponíveis no [link](https://www.conventionalcommits.org/pt-br/v1.0.0/).
|
|
|
|
Mais informações estão disponíveis no link: [Conventional Commits](https://www.conventionalcommits.org/pt-br/v1.0.0/).
|
|
|
|
|
|
|
|
Além desse padrão, estamos usando a ferramenta [Husky](https://typicode.github.io/husky/) para padronizar os commit. O husky roda dois comandos ao tentar fazer um commit, ele primeiro, verifica a mensagem do commit para ver se está de acordo com o padrão do projeto, e segundo, ele executa o comando `lint-staged` descrito no package.json
|
|
|
|
|
| ... | ... | @@ -117,9 +120,9 @@ Para commits onde teve participação de mais de um autor. Siga o exemplo abaixo |
|
|
|
`Co-Authored-By: Nome Sobrenome <[email protected]>`
|
|
|
|
|
|
|
|
|
|
|
|
#### Merge Request (MR)
|
|
|
|
## Merge Requests
|
|
|
|
|
|
|
|
Merge request deve ser criado apenas ao finalizar a task com todos seus objetivos atingidos. Ao criar o MR o responsável entende que seu código está pronto para ser entregue em produção.
|
|
|
|
Merge request(MR) deve ser criado apenas ao finalizar a task com todos seus objetivos atingidos. Ao criar o MR, o responsável entende que seu código está pronto para ser entregue em produção.
|
|
|
|
|
|
|
|
Cada projeto terá seu template de MR que deverá ser usado para descrever as mudanças realizadas. Campos não obrigatórios estarão descritos em comentários, os demais devem ser preenchidos pelo autor do MR.
|
|
|
|
|
| ... | ... | |
