GitLab

GitFlow

O que é?

GitFlow é um fluxo de trabalho no Git que auxilia na organização e versionamento de código. As definições tratadas ao longe deste documento de aplicam as repositórios de Fronted e Backend.

Como funciona?

O Git Flow trabalha com duas branches principais, a Develop e a Main, que duram para sempre; e duas branches de suporte, Feature e Hotfix, que são temporários e duram até realizar o merge com as branches principais.

Então, ao invés de uma única branch Main, esse fluxo de trabalho utiliza duas branches principais para registrar o histórico do projeto. A branch Mai armazena o histórico do lançamento oficial, e a branch Develop serve como uma ramificação de integração para recursos.

Modelo GitFlow

Branches protegidas

Main

Principal branch, aqui é onde temos todo o código de produção. Todas as novas funcionalidades que estão sendo desenvolvidas, em algum momento, serão mescladas ou associadas a Master.A branch é protegida e só pode ser alterada a partir de Merge Requests vindo diretamente da branch develop ou de branches de hotfix. Apenas AGES III e IV podem fazer merge dos MRs e realizar alterações nessa branch.

Develop

É a branch onde fica o código do próximo deploy. Ela serve como uma linha do tempo com os últimos desenvolvimentos, isso significa que ela possui funcionalidades que ainda não foram publicadas e que posteriormente vão ser associadas com a branch Main. Essa branch é protegida para modificação que não seja através de Merge Requests. Qualquer AGES pode criar um MR para a brach de desenvolvimento.

Branches não protegidas

Feature

São branches utilizadas para o desenvolvimento de funcionalidades específicas. É importante saber que essas branches são criadas sempre a partir da branch develop. Portanto, quando finalizada, elas são removidas após realizar o merge com a branch develop.

Fix

É uma branch para correção de bugs identificados ainda em desenvolvimento. Após o merge com a develop elas são removidas.

Hotflix

É uma branch criada a partir da master para realizar correções imediatas encontradas no sistema em produção. Quando concluída, ela é excluída após realizar o merge com as branches main e develop.

Padrão para criação de branches

As branches criadas para desenvolvimento das funcionalidades pelas squads devem seguir o padrão de acordo com seu objetivo:

Tags para os tipos de alterações:

• feature - Nova funcionalidade
• fix - Correção de defeito
• hotflix - Correção de bug em produção

feature/NUMERO_TASK

Exemplo: feature/12

Padrão para as mensagens de commit

Os commits deverão ter um padrão em suas mensagens para facilitar o entendimento da equipe no que foi desenvolvido:

"Descrição breve do commit - Autores (caso realizado em equipe)"

Exemplo: "Cadastro de instituições - Duda, Julia e Will"

OBS: Caso as atividades do commit tenham sido realizadas individualmente não é necessário informar os autores, porque a única pessoa envolvida será quem está subindo o commit.

Padrão para abertura de Merge Request

Os merge requests também devem seguir um padrão de criação:

O Title deve ser escrito UserStory - Título do Card no Trello e na Description deve ser informado o link para o card. Exemplo:

Title: US17 - Aceitar Requisição no feed de requisições
Description: link do card do Trello

Critério de aceite de Merge Requests (MR)

• Branch testada
• Branch atualizada com a DEV
• Arquitetura Respeitada
• Código Limpo

Comandos básicos

• clonar um repositório:
  git clone ADICIONAR URL
• verificar o status do repositório:
  git status
• CRIAR uma nova branch:
  git checkout -b <branch desejada>
• ALTERNAR para uma branch:
  git checkout <branch desejada>
• add arquivos alterados e dar um commit na branch:
  git commit -a -m 'adicionei um novo rodapé [issue 53]'
• primeira vez a enviar os dados para o repositório.
  git push origin <branch desejada>
• reenviar os dados para o repositório.
  git push
• baixar os dados do repositório.
  git pull
• fazer um merge em duas branch's.
  git merge <nome da branch>