|
|
## GitFlow |
|
|
\ No newline at end of file |
|
|
# 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.
|
|
|
|
|
|
* **main** (branch em produção a ser distribuída para as demais branches, código já testado, que será entregue ao cliente)
|
|
|
* **dev** (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 *devp*. Esta branch deve sempre conter o código mais atual)
|
|
|
|
|
|
**BRANCHES TEMPORÁRIAS**
|
|
|
|
|
|
Branches temporárias devem ser criadas para cumprir um objetivo(Ex.: Criar nova feature) e assim que esse objetivo for concluído a branch deve ser deletada.
|
|
|
|
|
|
* **US0xx** (branch utilizada para desenvolver novos recursos para o projeto. Esse tipo de branch é criado a partir da main, quando o novo recurso terminar de ser desenvolvido deve ser enviado para a *dev*). Nomenclatura *US0xx/descricao_da_tarefa*
|
|
|
* **Fix** (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 *fix* é criada a partir da main e deve ser utilizada para resolver o problema, assim que o problema for resolvido ela deve sofrer um merge para a *main*). Nomenclatura: *fix/descricao_da_tarefa*
|
|
|
|
|
|
*Observações:*
|
|
|
|
|
|
* xx nas brach US0 representa o número da US armazenada no ClickUp.
|
|
|
* A cada commit realizado deve ser descrito brevemente, em português, o que foi desenvolvido.
|
|
|
* Anexar imagens da tela caso seja um fix
|
|
|
|
|
|
## Ciclo de vida das Branches
|
|
|
|
|
|
### US0xx
|
|
|
|
|
|
1. Criar uma nova branch a partir da *main* seguindo a nomenclatura */descricao_da_tarefa*, onde o asterisco representa uma US armazenada no ClickUp.
|
|
|
1. Realizar commits na branch afim de desenvolver a funcionalidade.
|
|
|
1. Quando a Funcionalidade estiver completa realizar merge com a branch *dev*
|
|
|
|
|
|
### Fix
|
|
|
|
|
|
1. Criar uma branch a partir da branch main seguindo a nomenclatura *fix/descricao_da_tarefa*, onde o asterisco representa qualquer cadeia de caracteres.
|
|
|
1. Realizar commits nessa branch com o objetivo de resolver o bug.
|
|
|
1. Realizar o merge da fix 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. O merge request é uma solicitação de merge que os Ages IV e o Bruno Garcia AGES II (Aluno mais experiente em Flutter) vão avaliar para aprovar ou não esse merge. Sendo aprovado e não tendo conflito de commits o merge é feito automaticamente. |
|
|
\ No newline at end of file |