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. <Esc> wq!

Depois da mensagem, a tela de configuração de Tag é exibida. <Esc> wq!

Depois de tudo configurado, o Git Flow faz o merge para as branches Master e Develop, deleta a Release
criada e faz o checkout para a Develop já atualizada.

Passo 9 – Publicando a Master e a Develop

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

Agora, com o Release publicado e “mergeado” com a Master e a Develop, é necessário enviar para o
repositório remoto as alterações feitas na Master e na Develop.

Passo 10 – Criando um Hotfix

Comando: git flow hotfix start [nome_da_hotfix]

É comum surgirem bugs no sistema de produção e muitos deles não podem esperar o processo de Feature, Release, teste
e publicação. Pra isso o Fluxo de Hotfix foi criado. Ele é um Fluxo que segue a parte e depende somente da Master.

O comando mostrado cria um novo hotfix e faz o checkout para o mesmo criado.

Passo 12 – Finalizando a Hotfix

Comando: git flow hotfix publish [nome_do_hotfix] && git push origin hotfix [nome_do_hotfix]

Logo que o bug for corrigido e testado, o Hotfix pode ser publicado no repositóiro remoto.

Depois que configurados a publicação, o merge e a tag, o Git Flow faz o merge do Hotfix com a Master e a Develop.