Skip to content

GitLab

Last edited by Gabriel Franzoni
Page history

arquitetura

Página Inicial

Página da Arquitetura do Sistema

Nesta página encontra-se todas as políticas definidas pela equipe em relação ao uso do git, para tornar o desenvolvimento e uso do git mais fácil e eficiente de uma forma que todos os integrantes entendam. Também estão presentes os diagramas da aplicação, explicações sobre o Firebase e o Fluxo do funcionamento da aplicação que a equipe está desenvolvendo.

Conteúdo
Políticas do Git
Padrões de Código
Diagrama do Fluxo de Aplicação

Políticas do Git

Idealmente os commits devem ser pequenos e objetivos. O mesmo serve para Merge Requests. Commits e Merge Requests menores são mais fáceis de entender e revisar.

Branches de desenvolvimento idealmente devem existir por pouco tempo, o que reduz consideravelmente o número de conflitos e também ajuda no processo de revisão e merge.

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
  • chore: Tarefas relacionadas a infra, CI, configuração, etc

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 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.
  • A nomenclatura das branches de desenvolvimento seguem o template: {tipo}/{id-do-card-no-trello}/{pequena-descrição}
  • As opções de tipo no nome da branch são os mesmos dos tipos de commit.

trello_id

Sobre Merge Requests:

  • Fazer rebase com o master antes de abrir o Merge Request. Isso garante que possíveis conflitos sejam resolvidos antes do processo de revisão.

  • Sempre marque para remover a branch depois do merge.

delete_source_branch

Sobre Issues

Ao decorrer do projeto, além do desenvolvimento de novas features, é necessário corrigir bugs e outros erros que decorrem do desenvolvimento. Nem sempre nós temos tempo para corrigi-los, as vezes queremos opiniões de outros desenvolvedores em como resolver um problema, ou apenas queremos discutir o desenvolvimento de alguma funcionalidade. Para isso, existem as Issues.

Quando criar uma Issue, tente escrever um título curto, mas que expresse qual o problema. Na descrição, fale mais sobre o problema, como reproduzi-lo (caso seja algo muito específico), como pensa em resolve-lo (se não souber como, não tem problema) e qualquer outra coisa que julgue ser necessário.

Quando tiver corrigido um problema, na mensagem do commit que resolve aquele problema, coloque:

Closes #<numero_da_issue>

Isso permite que a Issue seja fechada automaticamente pelo GitLab. Além disso, na Issue, fica a hash do commit que fechou ela, então fica documentado para qualquer necessidade de referência futura.

Para mais informações sobre Issues acesse a documentação oficial do GitLab sobre essa feature.

Referências:

Padrões de código

Código em inglês (nomes de variáveis, funções, arquivos, etc.)

Seguiremos o guia de estilo do Dart, que é a documentação oficial para o estilo de código em Dart.

Nota: todos os guias contidos na documentação são ótimas fontes de referências e de conhecimento sobre linguagem. Recomendamos a leitura.

Referências:

Diagrama do Fluxo da Aplicação

fluxoDeAtividades__3_