Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • appoio-wiki appoio-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
  • APPOIO
  • appoio-wikiappoio-wiki
  • Wiki
  • git_workflow

Last edited by Rafael Victor Ruwer Araujo Oct 16, 2020
Page history
This is an old version of this page. You can view the most recent version or browse the history.

git_workflow

Home Sprints Requisitos Arquitetura Configuração Mockups Banco de Dados Instalação Deploy Rotas Gerência Time Padronização Git Workflow Qualidade

Git Workflow

Acesso rápido

  • Branches
  • Commits
  • Merge requests

Branches

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:

git pull

Como padrão para nomes de branches, foi decidido o seguinte:

<código da tarefa>/<nome da tarefa separado por hífen sem acentuação>

Por exemplo:

ap-12/componente-campo-de-texto

Assim que a branch for criada execute o seguinte comando:

git push --set-upstream origin <nome da branch>

Isso irá garantir que a branch seja enviada para o repositório remoto no GitLab, permitindo que outros membros do time tenham acesso a mesma.

Commits

Para facilitar o desenvolvimento, faça commit sempre que alguma funcionalidade for alterada, assim garantindo um método fácil de recuperação do código (caso necessário).

Como padrão para mensagens de commit, foi decidido o seguinte:

<código da tarefa>: <autor1>, <autor2> e <autor3>
<descrição da tarefa>
  • código da tarefa: Código indicado na tarefa no Trello.
  • autor1, autor2 e autor3: Nome sobrenome das pessoas que contribuíram para aquele commit.
  • descrição da tarefa: Descrição da alteração realizada, escreva de forma sucinta e clara.

Por exemplo:

12: João Leão e Eduardo Cardoso

Estilização do input, documentação do componente e correção de bug no value

Para escrever mais de uma linha de commit pelo terminal padrão escreva o seguinte comando:

git commit -m "

Depois pressionar enter, escreva toda a mensagem, digite " novamente e pressione enter para enviar.

Merge requests

Assim que uma tarefa for finalizada execute o seguinte comando:

git pull origin dev

O mesmo irá garantir que sua branch está atualizada com a branch dev (caso haja conflitos, resolva-os) e realize um commit com o seguinte nome:

Merge branch 'master' into '<nome da branch>'

Depois de estar com a sua branch remota pronta para merge, crie um Merge Request no GitLab e preencha com as seguintes informações:

  • Source Branch: Sua branch.
  • Target Branch: branch dev.
  • Assignees: Membro do time responsável pela verificação do código (AGES 3 ou AGES 4)
  • Título: <número da tarefa>/<nome da tarefa separado por hífen sem acentuação>
  • Descrição: Descrição da tarefa e/ou das mudanças no código

Assim que for criado o Merge Request avise um AGES 3 ou AGES 4.

Agora a mesma será verificada por um AGES 3 ou AGES 4 para que (depois de aprovada) seja marcado como concluído na check list do Trello.

  • O verificador não poderá ter participado do desenvolvimento da tarefa;
  • A funcionalidade deve ter sido implementada de acordo com sua descrição;
  • A funcionalidade deve ser fiel aos Mockups (dadas as devidas proporções);
  • O código deve ser fácil de entender e legível;
  • O código deve ser desenvolvido e propriamente documentado de acordo com a padronização do projeto;
Clone repository
  • Rotas
  • arquitetura
  • banco_dados
  • configuracao
  • deploy
  • escopo
  • git_workflow
  • gp
  • Home
  • instalacao
  • mockups
  • padronizacao
  • processo
  • qualidade