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 desenvolvimento (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 + indicado como 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 atual de volta pro branch de desenvolvimento.
+"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, para aquela última + verificada.
+"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 que tu faz é 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
+ +Ou seja: tudo se resume à: git flow feature start, fazer as alterações, verificar se os
+ testes locais passam e fazer um git push.