Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Bem Estar
  • wiki
  • Wiki
  • arquitetura

arquitetura · Changes

Page history
doc: Update arquitetura with Git policies authored Mar 25, 2020 by João Etchichury Soares's avatar João Etchichury Soares
Hide whitespace changes
Inline Side-by-side
arquitetura.md
View page @ e69641a4
......@@ -18,9 +18,52 @@ funcional)
Design do Projeto
* Análise dos principios SOLID
* Code Review
*
Devem ser apresentados das seguintes formas:
* Imagens ou Gifs
* Diagramas ou Sistemas
* Descrições ou Textos explicativos
\ No newline at end of file
* 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
Clone repository
  • arquitetura
  • banco_dados
  • configuracao
  • gp
  • Home
  • instalacao
  • mockups
  • requisitos
  • sprints