Skip to content

Latest commit

 

History

History
executable file
·
38 lines (25 loc) · 1.78 KB

estrutura.md

File metadata and controls

executable file
·
38 lines (25 loc) · 1.78 KB

Estrutura de um Git Flow

Quando você começa a estudar um tipo de GitFlow, a primeira coisa a se entender são as responsabilidades de cada tipo de branch. Entenda o Gitflow como uma hierarquia a ser seguida, onde você não pode pular nenhum processo ou irá gerar algum tipo de conflito em certo ponto.

Vamos analisar a lista de branches abaixo:

Master─────────────────────Hotfix
│
└──────Releases────────────Bugfix
       │
       └─────Develop───────Bugfix
             │
             └─────Features
                   │
                   └───────Tasks

Podemos ver as branches em cascata, que sempre partem de uma tarefa e vão subindo gradualmente até chegarem na branch principal (master). Tá, mas o que quer dizer cada uma dessas branchs? Segue a função de cada branch abaixo:

  • Master - branch responsável pelo ambiente que roda em Produção

  • Hotfix(es) - responsável por corrigir algum erro critico que impeça o cliente de executar alguma função em ambiente de produção.

  • Releases - responsável por gerenciar e documentar todas as alterações feitas a cada deploy

  • Bugfix(es) - responsável por corrigir bugs pequenos em ambiente de desenvolvimento (develop) ou homologação (release).

  • Develop - branch onde sempre será criada e/ou mergeadas novas features

  • Features - branchs responsáveis por desenvolver estórias do projeto

  • Tasks - branch relacionada a uma feature (estória) descrevendo sempre um objetivo a ser trabalhado

Seguindo o projeto com esse fluxo, há maiores garantias de que ninguém no time irá atropelar ou perder código em merges falhos onde haverão conflitos.

Ir para: 4.3 Releases