Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • ENSportive Wiki ENSportive Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 11
    • Issues 11
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ENSportive
  • ENSportive Wiki ENSportive Wiki
  • Wiki
  • Processos

Last edited by Mateus Campos Caçabuena Jun 29, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Processos

Documentação do negócio

Documentação técnica

|---|---|---|---|---|---|---|---|---|---|---|

Processo de Desenvolvimento

Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira como o time se organizou e trabalha.

Sumário

  • Git Workflow
  • Template Pull Request

Git Workflow

Nomes das Branches

Para padronizarmos os nomes das branches, deve-se nomeá-las da seguinte forma:

<UserStory>-<Descrição>

Como por exemplo:

US04-DesenvolverLogin

Semântica dos Commits

Para padronizarmos a descrição dos commits, será utilizado um padrão semântico a fim de facilitar o compreendimento de cada commit. Os padrões serão os seguintes:

  • feature: Tratam adições de novas funcionalidades ou de quaisquer outras novas implantações ao código;
  • fix: Essencialmente definem o tratamento de correções de bugs;
  • docs: referem-se a inclusão ou alteração somente de arquivos de documentação;
  • test: Adicionando testes ausentes ou corrigindo testes existentes nos processos de testes automatizados (TDD);
  • build: Alterações que afetam o sistema de construção ou dependências externas (escopos de exemplo: gulp, broccoli, npm),
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs);
  • perf: Uma alteração de código que melhora o desempenho;
  • refactor: Tipo utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada;
  • style: Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.);
  • chore: Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas que realmente não entram em produção;
  • env: basicamente utilizado na descrição de modificações ou adições em arquivos de configuração em processos e métodos de integração contínua (CI), como parâmetros em arquivos de configuração de containers.

Exemplo da descrição commit:

fix-loginError

Criando uma Branch

Para criar uma branch e começar a trabalhar nela, 3 comandos git serão essenciais, vejamos abaixo quais são eles:

git checkout develop # Vai para a branch ‘development’.
git pull # Puxa as modificações remotas.
git checkout -b <NOME_DA_SUA_BRANCH_AQUI> # Cria uma nova branch.

Utilizando os comandos acima, você estará indo para a branch ‘develop’, puxando todas as modificações remotas e criando uma nova branch a partir de ‘develop’. Você então passará a trabalhar na nova branch criada.

Clone repository
  • Arquitetura
  • Banco de Dados
  • Configuração
  • Gerência
  • Processos
  • Home
  • mockups
  • sprints