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
  • HiperBem
  • wiki
  • Wiki
  • git workflow

Last edited by Guilherme Piccoli Sep 23, 2019
Page history
This is an old version of this page. You can view the most recent version or browse the history.

git workflow

Home Cronograma Sprints Requisitos Gerência de Projeto Horários Disponiveis
Mockups Banco de Dados Material de estudo Arquitetura Git Workflow Configuração

## Definition of Done

Uma tarefa é dada como pronta quando seu merge request para a branch Dev for avaliado por um AGES 3 ou AGES 4, e aprovado sob os seguintes termos:

  • O avaliador não participou do desenvolvimento da tarefa.
  • A funcionalidade deve estar implementada de acordo com o definido na tarefa.
  • O código deve ser fácil de entender e legível.
  • O código segue os padrões de estruturação do projeto.

## Mensagem de Commit

É recomendado evitar commits com muitas funcionalidades e/ou alterações, pois isso dificulta o controle das versões e alterações feitas no código. O modelo de mensagem de commit é o seguinte:

<número da tarefa>: <autor1>, <autor2>

<descrição da tarefa>
  • número da tarefa é correspondente ao número indicado na tarefa no Trello.
  • autor1, autor2 nomeia as pessoas que contribuíram para aquele commit, não necessariamente são todas as pessoas que estão escaladas para aquela tarefa.
  • descrição da tarefa, descrição do que o commit adiciona ao código/projeto, utilize linguagem imperativa e escreva de forma sucinta e clara.

Por exemplo:

67: Fernando, Gabriel Franzoni

Adiciona dependência nova, mostra alerta quando usuário insere senha errada.

## Nomeação de Branches

Lembre-se de dar um pull da versão remota da branch dev sempre que você for criar um branch nova, garantindo que ela é criada a partir da versão estável mais atual. Como padrão para nomes de branches, foi decidido o seguinte:

<número da tarefa>/<nome da tarefa separado por hífen sem acentuação>

Por exemplo:

67/Validacao-e-alertas-campo-de-senha


## Merge Requests
  • Quando você terminar sua tarefa, dê um pull na branch remota da dev para a sua branch atual e garanta que não existem conflitos com as suas alterações
  • Suba as suas alterações para o remoto
  • Abra o GitLab e crie um novo Merge Request
  • No título do Merge Request escreva o número da tarefa e seu nome
  • Na descrição, descreva a tarefa
  • Em Assignees, selecione todas os membros aos quais essa tarefa foi delegada
  • Finalize a criação do Merge Request

Lembre-se de garantir que a source branch selecionada é a sua e a target branch é a dev (fora exceções). Também garanta que não existem conflitos entre as branches antes de submeter o Merge Request. Caso o Merge Request for aprovado, use o comando git branch -d <número da tarefa>/<nome da tarefa separado por hífen sem acentuação> para excluir sua branch local.

Clone repository
  • arquitetura
  • banco_dados
  • configuracao
  • cronograma
  • git workflow
  • gp
  • Home
  • horarios
  • material de estudo
  • mockups
  • padronização
  • requisitos
  • retrospectivas
  • sprints
  • testes