GIT Flow

O que é o GIT Flow?

GIT Flow é um módulo extra para GIT para gerenciar o fluxo de desenvolvimento padrão usando GIT.

Hoje está tão difundido que praticamente todas as distribuições que tem o GIT tem um pacote para GIT Flow (incluindo Windows).

Fluxo de Desenvolvimento Padrão

(ou, pelo menos, o esperado)

• trunk/master tem a versão estável do projeto.
• Existe pelo menos um branch de desenvolvimento.
• Coisas são desenvolvidas no branch de desenvolvimento e depois passadas para o trunk/master.

Fluxo de Desenvolvimento Anabolizado

• Trunk/master tem a versão estável do projeto.
• Existe um branch de integração.
• Cada feature tem um branch especializado.
• Branches são testados individualmente e depois testados de novo no branch de integração (para que sejam feitos os testes de integração) e depois passados parao trunk/master.

Praticamente comum em SCVs com criação de branchs rápidas (como o GIT).

Começando com GIT Flow

git flow init

					Branch name for production releases: [master] 
					Branch name for "next release" development: [develop] 

					How to name your supporting branch prefixes?
					Feature branches? [feature/] 
					Release branches? [release/] 
					Hotfix branches? [hotfix/] 
					Support branches? [support/] 
					Version tag prefix? [] 
					

• Qual o branch estável/de produção?
• Qual o branch de integração/desenvolvimento?
• Qual o prefixo dos branches de features/correções?
• Qual o prefixo dos branches de releases?
• Qual o prefixo dos branches de correções emergenciais?
• Qual o prefixo das tags de versão?

(Branches de suporte são experimentais: branches criados a partir do master que nunca são feitos merge de volta.)

Como Funciona Esse Workflow?

"Vou começar uma feature nova."

git flow feature start minha_feature

Irá fazer um fork do branch de desenvolvimento com o nome "minha_feature".

(feature start vai começar outro branch a partir do desenvolvimento, não do branch de feature atual.)

"Terminei minha feature."

git flow feature finish

Faz o merge do branch de desenvolvimento com o branch da feature e, se tudo ocorreu sem problemas, faz o merge do branch da feature de volta pro branch de desenvolvimento e destrói o branch da feature.

"Todas as minhas features estão prontas"

git flow release start versão

Cria um branch de release a partir do master e faz um merge com o branch de desenvolvimento.

"Todas as features estão ok"

git flow release finish

Faz o merge da release atual para o master, destrói o branch de release, bota a tag da versão no commit, faz o merge do branch master com desenvolvimento.

"Fuck, deu algo errado em produção"

git flow hotfix start fuckingdevs

Cria um branch a partir do master, passando por cima do desenvolvimento.

"Ok, agora deve resolver o problema de produção"

git flow hotfix finish

Faz o merge do branch de hotfix de volta pro master, faz o merge do master com o branch de desenvolvimento.

Pequeno lembrete: todos os branches do git flow são locais.

Por que isso é importante?

Eu uso SVN!

Com branches locais, qualquer alteração é feita localmente na máquina.

git svn dcommit vai mandar o branch atual pro repositório, então se você estiver no seu master... Vai o que estiver depois do git flow release finish.

Parênteses

O conceito de fluxos do GIT está tão difundido que já existem soluções prontas para:

• Adicionar o reconhecimento de novos branches por ferramentas de integração contínua.
• Executar testes nos branches novos.
• Verificam a possibilidade de merge se passar pelos testes.
• Se passam os testes e pode ser feito o merge, já faz o merge para desenvolvimento (ou, dependendo do caso, criar um merge request automático).

Parênteses (cont.)

Ou seja: tudo se resume à: git flow feature start, fazer as alterações, verificar se os testes locais passam e fazer um git push.