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 xx/descricao_da_tarefa, onde o xx representa uma US armazenada no ClickUp.
2. Realizar commits na branch afim de desenvolver a funcionalidade.
3. 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.
2. Realizar commits nessa branch com o objetivo de resolver o bug.
3. 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.

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:

• main

• dev

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

• fix/[descrição_do_bug] para main

• US0xx/[descrição_da_tarefa] para dev

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]