GitFlow

Fluxo de trabalho Gitflow

O Git Flow é uma maneira dinâmica e ativa de organização de branches dentro do Git. Com base nessa metodologia,
o Git Flow criou um ferramental para auxiliar esta administração. Ele agrupa um conjunto de comandos dentro de um único comando
o intuito de auxiliar no gerenciamento e na manutenção do repositório.

Os ramos (branches)

Master

A branch Master é a cópia fiel do sistema em produção, um espelho de todo o sistema que está operando em produção.
Em tese, se algo acontece com o sistema de produção, a master deve estar preparada para subir para produção e continuar
operando normalmente como antes. Só deve existir uma branch Master no projeto, apenas um Fluxo (Flow) de evolução.

Develop

A branch Develop é a base de trabalho e desenvolvimento do projeto. A Develop sempre está sincronizada com a Master, sempre.
Todas as novas funcionalidades (Features) e toda a evolução do projeto é feita com base na branch Develop. Assim como a Master,
só deve existir apenas uma branch Develop, apenas um Fluxo (Flow) de evolução.

Features

A branch Features é o conjunto de branches que compõe toda a evolução do projeto. Com base na Develop, toda nova funcionalidade a
ser implementada no sistema é feita pelo Fluxo (Flow) Features. Neste caso, podem existir N branches para este Fluxo (Flow).
Em um mesmo Fluxo Features várias branches de novas funcionalidades podem coexistir simultaneamente. Todas serão “mergeadas” uma a uma para a Develop.

Release

E a branch que controla a versão do sistema. Quando há uma quantidade X de merges das Features com a Develop, um novo Release pode ser criado,
criando uma nova versão para o sistema. Cada arquiteto ou responsável pelo projeto decide quando criar uma nova Release com base no que já foi produzido.
Geralmente é nesta branch que acontecem todos os tipos de testes. Quando um Release é aprovado, ele é “mergeado” com a Master e com a Develop,
para manter a base de desenvolvimento atualizada. Só deve existir apenas uma branch Release, apenas um Fluxo de evolução (Flow).

Hotfixes

Esta branch é utilizada para gerar correções que ocorrem em produção. Geralmente um erro no sistema de produção não pode esperar todo o
fluxo de Develop, Feature, Release pra depois voltar para a Master. Erros no sistema de produção requerem imediatismo e é pra isso que a Hotfies existe.
Quando um erro é encontrado em produção, uma Hotfix é criada com base na Master, corrigida e “mergeada” de volta para a Master e juntamente para a Develop.
É muito importante a Develop receber esta atualização, pois se isto não for feito, o problema outrora corrigido pode voltar depois de uma nova Release.
Não é aconselhável existirem várias branches de Hotfixes, mas muitas equipes optam por terem quando o sistema tem uma incidência muito grande de erros
acontecendo em produção.

Iniciando o Git Flow

O Git Flow segue uma sequência de fluxos de branches e com base nesse fluxo todo o ciclo de vida do projeto é mantido atualizado e versionado.

Passo 1 – Clonando o repositório

Comando: git clone git@us-south.git.cloud.ibm.com:sheila.prado/redome-workup.git

O processo de clonar o repositório é o mesmo do Git nativo como mostrado a seguir:

Passo 2 – Iniciando o Git Flow no projeto

Comando: git flow init -d

No momento da instalação o Git Flow mostrará os passos de configuração das branches de base.
Um padrão já vem configurado e é aconselhável deixar a configuração padrão.

Após a finalização do processo é possível ver que um simples comando já configura o ambiente e
ainda cria a branch de desenvolvimento develop.

Passo 3 – Enviando para o Git as branches criadas

Comando: git push origin master && git push origin develop

Depois de criado as branches, é necessário enviá-las para o repositório remoto.
Depois disto, a evolução do projeto poderá ser iniciada.

Passo 4 – Iniciando uma nova Feature

Comando: git flow feature start [nome_da_feature]

Este comando é mais um exemplo de várias ações dentro de um único comando. Após executar o comando de
criação de Feature, o Git Flow cria a branch no Fluxo Feature e em seguida faz o checkout para a Feature criada.

Passo 5 – Criar um novo arquivo e enviá-lo para o repositório remoto

Comando: git push origin feature/[nome_da_feature]

Após a criação da nova Feature, os arquivos já podem ser criados e a evolução ocorre normalmente, os commits
locais podem ser feitos e, ao terminar, é necessário enviar toda a implementação feita para o repositório remoto
juntamente com a branch Feature criada no repositório local.

A imagem a seguir mostra que a branch Feature foi criada no repositório remoto.

Passo 6 – Finalizando a Feature criada

Comando: git flow feature finish [nome_da_feature]

Apenas um único comando é necessário para fazer o merge da Feature com a Develop, excluir a Feature criada
e fazer o checkout para a branch Develop.

Passo 7 – Criando um Release

Comando: git flow release start [versao_da_release]

Após um conjunto de Features ter sido criado e “mergeados” com a Develop, um novo Release pode ser criado.
Não há uma regra para quando um Release é criado, esta decisão cabe da equipe e dos responsáveis pelo projeto.

Ao executar o comando de criação de Release, o Git Flow cria a Release e faz o checkout para a nova branch criada.

Passo 8 – Publicando a Release

Comando: git flow release publish [versao_da_release]

Depois de todas as validações e testes necessários no Release criado, é possível publicar sua versão.

O comando de publicar um Release envia todo o conteúdo para o repositório remoto.

Em seguida, é necessário colocar uma mensagem para a publicação da Release.

Depois da mensagem, a tela de configuração de Tag é exibida.