| ... | @@ -18,9 +18,52 @@ funcional) |
... | @@ -18,9 +18,52 @@ funcional) |
|
|
Design do Projeto
|
|
Design do Projeto
|
|
|
* Análise dos principios SOLID
|
|
* Análise dos principios SOLID
|
|
|
* Code Review
|
|
* Code Review
|
|
|
*
|
|
|
|
|
Devem ser apresentados das seguintes formas:
|
|
Devem ser apresentados das seguintes formas:
|
|
|
|
|
|
|
|
* Imagens ou Gifs
|
|
* Imagens ou Gifs
|
|
|
* Diagramas ou Sistemas
|
|
* Diagramas ou Sistemas
|
|
|
* Descrições ou Textos explicativos
|
|
* Descrições ou Textos explicativos
|
|
|
|
|
|
|
|
## Políticas do Git
|
|
|
|
|
|
|
|
### Sobre mensagens de commit:
|
|
|
|
|
|
|
|
- Em inglês
|
|
|
|
- As mensagens devem estar no modo imperativo
|
|
|
|
- Utilizar mais ou menos 50 caracteres
|
|
|
|
- A mensagem sempre começa com letra maiúscula
|
|
|
|
- A mensagem não tem ponto final
|
|
|
|
- Sempre especificar o tipo de commit
|
|
|
|
- Usar o corpo da mensagem (quando necessário) para explicar "o que" e "por que"
|
|
|
|
|
|
|
|
**Tipos de commits**
|
|
|
|
|
|
|
|
- feature: Alterar comportamento, interface ou adicionar nova funcionalidade
|
|
|
|
- fix: Correção de bugs
|
|
|
|
- doc: Alteração da documentação, README, CHANGELOG, etc
|
|
|
|
- style: Formatação, ponto e vírgula faltando, mudanças de whitespace, estilo de código no geral
|
|
|
|
- refactor: Refatoração do código de produção, nenhuma ateração de funcionalidade ou comportamento
|
|
|
|
- test: Adicionar testes, refatorar testes; código de produção não é alterado
|
|
|
|
|
|
|
|
**Exemplos**
|
|
|
|
|
|
|
|
feature: Add search videos page
|
|
|
|
fix: Stop ignoring keywords when searching
|
|
|
|
doc: Add examples to the contributing guide
|
|
|
|
style: Remove empty line
|
|
|
|
refactor: Move related methods close together
|
|
|
|
test: Add spec for api video controller
|
|
|
|
|
|
|
|
### Sobre branches:
|
|
|
|
|
|
|
|
- Master: é a base do projeto. É dela que as outras branches serão criadas. Onde ocorrerá o `merge` das branches de desenvolvimento. Utilizaremos [Semantic Versioning](https://semver.org/) para mantermos o controle de versão da nossa aplicação.
|
|
|
|
- Branches de desenvolvimento: onde novas funcionalidades são desenvolvidas e erros são corrigidos. Lembrando que elas sempre são criadas a partir da `master`.
|
|
|
|
|
|
|
|
### Referências:
|
|
|
|
|
|
|
|
- https://chris.beams.io/posts/git-commit/
|
|
|
|
- https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/
|
|
|
|
- https://semver.org/
|
|
|
|
- https://www.conventionalcommits.org/en/v1.0.0/#summary
|
|
|
|
- https://dhwthompson.com/2019/my-favourite-git-commit |
