| ... | ... | @@ -15,7 +15,87 @@ Esta página descreve os processos utilizados pelo time ao longo do projeto. |
|
|
|
|
|
|
|
### Fluxo de trabalho no Git
|
|
|
|
|
|
|
|
TODO
|
|
|
|
Como modelo de fluxo de trabalho no Git iremos nos basear no Git Flow, para termos um maior controle sobre as alterações sendo realizadas no projeto, por meio de Merge Requests, e para conseguirmos lidar bem com muitas pessoas realizando alterações em um repositório ao mesmo tempo.
|
|
|
|
|
|
|
|
#### Branches
|
|
|
|
Neste modelo, cada repositório possui duas branches principais:
|
|
|
|
|
|
|
|
- **dev** - branch utilizada durante o desenvolvimento, onde todas as novas funcionalidades e correções que ainda não foram publicadas no ambiente de produção serão mescladas.
|
|
|
|
- **main** - branch cujo código é utilizado no ambiente de produção (APK), onde novas versões/releases serão mescladas quando estiverem prontas para serem publicadas.
|
|
|
|
|
|
|
|
Além disso, para realizar alterações no projeto, podem ser criados outros 2 tipos de branch:
|
|
|
|
|
|
|
|
- **feature branch** - branch criada a partir da develop para desenvolvimento de uma nova funcionalidade.
|
|
|
|
- **fix branch** - branch criada a partir da dev para desenvolvimento de correções de bugs.
|
|
|
|
|
|
|
|
Por padrão, o nome destas duas branches deve iniciar com o tipo de branch (`feat/` ou `fix/`), seguido pelo identificador da User Story, e por fim o identificador da tarefa presente no board.
|
|
|
|
> Exemplo: fix/US02-5
|
|
|
|
|
|
|
|
#### Commits
|
|
|
|
Para fins de padronização e melhor organização, utilizaremos Conventional Commits para mensagens de commits.
|
|
|
|
|
|
|
|
##### Como utilizar
|
|
|
|
A convenção segue o seguinte formato:
|
|
|
|
```
|
|
|
|
!type(?scope): !subject
|
|
|
|
```
|
|
|
|
> Dessa maneira, ! indica os atributos obrigatórios e ? indica os atributos não obrigatórios.
|
|
|
|
|
|
|
|
- tipo de commit (type)
|
|
|
|
- o escopo/contexto do commit (scope)
|
|
|
|
- assunto/mensagem do commit (subject)
|
|
|
|
|
|
|
|
###### Subject: Imperativo ao invés de pretérito
|
|
|
|
Ao escrever subjects utilizando o imperativo nós estamos dizendo à nossa equipe _o que fará o commit se aplicado_.
|
|
|
|
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
|
|
refactor: change the markup
|
|
|
|
```
|
|
|
|
Ou seja, "If applied, this commit will change the markup"
|
|
|
|
|
|
|
|
###### Type: Quais são os tipos de commit
|
|
|
|
O _type_ é responsável por nos dizer qual o tipo de alteração ou iteração está sendo feita, das regras da convenção, temos os seguintes tipos:
|
|
|
|
|
|
|
|
- `feat`: indica o desenvolvimento de uma nova feature ao projeto.
|
|
|
|
Exemplo: Acréscimo de um serviço, funcionalidade, endpoint, etc.
|
|
|
|
- `fix`: utilizado quando há correção de erros que estão gerando bugs no sistema.
|
|
|
|
Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.
|
|
|
|
- `refactor`: usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema.
|
|
|
|
Exemplo: Mudanças de código após um code review
|
|
|
|
- `style`: empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma.
|
|
|
|
Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc..
|
|
|
|
- `chore`: indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento.
|
|
|
|
Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore
|
|
|
|
- `docs`: usado quando há mudanças na documentação do projeto.
|
|
|
|
Exemplo: adicionar informações na documentação da API, mudar o README, etc.
|
|
|
|
- `build`: utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas.
|
|
|
|
Exemplo: Gulp, adicionar/remover dependências do npm, etc.
|
|
|
|
- `perf`: indica uma alteração que melhorou a performance do sistema.
|
|
|
|
Exemplo: alterar ForEach por while, melhorar a query ao banco, etc.
|
|
|
|
- `ci`: utilizada para mudanças nos arquivos de configuração de CI.
|
|
|
|
Exemplo: Circle, Travis, BrowserStack, etc.
|
|
|
|
- `revert`: indica a reverão de um commit anterior.
|
|
|
|
- `test`: indica qualquer tipo de criação ou alteração de códigos de teste.
|
|
|
|
Exemplo: Criação de testes unitários.
|
|
|
|
|
|
|
|
###### Observações
|
|
|
|
- Só pode ser utilizado um _type_ por commit;
|
|
|
|
- A diferença entre `build` e `chore` pode ser um tanto quanto sutil e pode gerar confusão, por isso devemos ficar atentos quanto ao tipo correto. No caso do Node.js por exemplo, podemos pensar que quando há uma adição/alteração de certa dependência de desenvolvimento presente em devDependencies, utilizamos o chore. Já para alterações/adições de dependências comuns aos projeto, e que haja impacto direto e real sobre o sistema, utilizamos o build.
|
|
|
|
|
|
|
|
###### Scope: contextualizando o commit
|
|
|
|
Em repositórios enormes, como monorepos, ou projetos com várias features e mudanças paralelas, não fica bastante claro até onde a mudança que irá chegar pode alterar. Para isso, podemos utilizar o _escopo(scope)_ do commit.
|
|
|
|
|
|
|
|
Exemplo:
|
|
|
|
```
|
|
|
|
feat(UserService): add getAppointments endpoint
|
|
|
|
```
|
|
|
|
Desse modo é entendível que a mudança feita é no domínio do UserService.
|
|
|
|
|
|
|
|
---
|
|
|
|
#### Referências
|
|
|
|
- [GitFlow](https://www.atlassian.com/br/git/tutorials/comparing-workflows/gitflow-workflow)
|
|
|
|
- [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
|
|
|
|
|
|
|
|
### Práticas de CI/CD
|
|
|
|
|
| ... | ... | |
