Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • P painfree-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
  • Pain Free
  • painfree-wiki
  • Wiki
  • GitFlow

Last edited by Denise Telli Jun 12, 2021
Page history

GitFlow

Home Gerenciamento Banco de Dados Arquitetura Desenvolvimento
Configuração Mockups Git

GitFlow

Modelo de organização de branches para o git. Estabelece algumas regras de nomenclaturas para tipos de branches enquanto e define o que cada tipo de branch faz.

Branches

BRANCHES PERMANENTES

Branches que vão ser mantidas durante todo o período de desenvolvimento do projeto. Elas devem ser protegidas para manter um histórico de alterações claro e conciso.

  • Master (branch em produção a ser distribuida para as demais branches, código já testado, que será entregue ao cliente)

  • Develop (branch para integração das alterações de desenvolvimento que já foram finalizadas. A partir daqui vai ser gerado o ambiente de desenvolvimento e features finalizadas devem enviar suas alterações para a develop.Deve sempre conter o código mais atual)

BRANCHES TEMPORÁRIAS

Branches temporarias devem ser criadas para cumprir um proposito e assim que esse proposito for concluído a branch deve ser apagada.

  • Feature (branch utilizada para desenvolver novos recursos para o projeto. Esse tipo de branch é criado a partir da master, quando o novo recurso terminar de ser desenvolvido deve ser enviado para a develop). Nomenclatura feature/descricao_da_tarefa
  • Bugfix (branch para correção de erros encontrados em produção. Esse tipo de branch tem por objetivo resolver o problema o mais rapidamente possível. Para isso a branch bugfix é criada a partir da master e deve ser utilizada para resolver o problema, assim que o problema for resolvido ela deve sofrer um merge para a master). Nomenclatura: bugfix/descricao_da_tarefa

Observações:

  • A descrição da tarefa deve incluir o número da US (airtable).
  • A cada commit realizado deve ser descrito brevemente, em português, o que foi desenvolvido.
  • Anexar imagens da tela caso seja um bugfix

Ciclo de vida das Branches

Feature

  1. Criar uma nova branch a partir da master seguindo a nomenclatura /descricao_da_tarefa, onde o asterisco representa qualquer cadeia de caracteres.
  2. Realizar commits na branch afim de desenvolver a funcionalidade.
  3. Quando a Funcionalidade estiver completa realizar merge com a branch develop

Bugfix

  1. Criar uma branch a partir da branch master seguindo a nomenclatura bugfix/descricao_da_tarefa, onde o asterisco representa qualquer cadeia de caracteres.
  2. Realizar commits nessa branch com o objetivo de resolver o bug.
  3. Realizar o merge da bugfix com a branch master

Gerenciamento de branches no GitLab

Merge Request (MR)

Quando finalizamos o desenvolvimento de uma branch e queremos enviar suas alterações para outra branch precisamos criar um merge request. Omerge request é uma solicitação de merge que os Ages III e Ages IV vão avaliar para aprovar ou não esse merge. Sendo aprovado e não tendo conflito de commits o merge é feito automaticamente.

Criando um MR

Para criação de um MR basta você clicar em Merge Requests no menu principal e então depois em new merge request. Após isso, você seleciona a branch de origin e a branch de destino que você deseja submeter e então clica no botão comparar branches e continuar. Nessa tela então você vai definir o título de seu MR (de preferência o nome da tarefa ou User story) e então selecionar o template do MR conforme as imagens a seguir:

1. Clique em choose template

2. Selecione o template de NovaFeature

3. Dentro da descrição do MR vão aparecer alguns os campos que devem ser preenchidos

4. Dar assign para você no MR e marcar para deletar a branch

Após esses passos você clica em submit merge request.

Aprovação do Merge Request

O merge request só será aprovado se tiver ao menos dois Joinhas 👍, sendo pelo menos um deles de um membro AGES 3 ou 4, além de não apresentar nenhum conflito.

Ciclo de Vida Gitflow - do MR à Publicação

Branchs fixas atuais:

• master

• develop

MR serão aprovados para as branchs respeitando a nomenclatura definida na imagem abaixo:

• bugfix/[número da feature] para master

• feature/[número da feature] para develop

Terminal

Comandos básicos

Clonar o repositório

git clone [Link do repositório]

Criação de uma nova branch

git checkout -b [nome da branch]

Trocar entre branchs

git checkout [nome da branch]

Deletar uma branch

git branch -d [nome da branch]

Pegar modificações da branch remota

git pull [nome da branch remota]

Adicionar arquivos modificados

git add [nome do arquivo modificado]

Adicionar um commit

git commit -m "uma mensagem sobre as alterações feitas"

Adicionar um commit com mais de um autor

git commit -m "Refactor usability tests.
>
>
Co-authored-by: name <[email protected]>
Co-authored-by: another-name <[email protected]>"

Observação: o símbolo > significa uma linha vazia

Adicionar as alterações a branch remota

git push [nome da branch remota]
Clone repository
  • GitFlow
  • Reviews
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • arquitetura
  • banco_dados
  • configuracao
  • cronograma
  • escopo
  • gp
  • Home
  • horarios
  • instalacao
  • matriz
View All Pages