Git [X] Flow

O objetivo neste artigo é abordarmos os mais conhecidos flows hoje utilizados com o GIT, e de uma maneira mais simples e resumida dar condições de se realizar uma boa escolha 😬

Git Flow

O flow mais conhecido até hoje. Ele foi criado por Vincent Driessen em 2010 e é baseado em duas branches com tempo de vida indeterminado:

• Master|Main — Esta branch contém código de produção, e todo código final chega aqui (merged), após sua aprovação
• Development — O nome desta branch já diz muito e digamos que ela recebe o código de pré-produção.

Durante o ciclo de desenvolvimento, uma variedade de branches são utilizadas:

• Feature — Este tipo de branch normalmente é utilizada para desenvolver novas features para próximos lançamentos. Normalmente se deriva da branch de development e tem como destino final a branch de development.
• Hotfix — Esta branch normalmente traz modificações necessárias e imediatas para serem aplicadas na Master|Main, por conta de algum problema e/ou status indesejado. Ela pode se derivar da Master|Main, tem que ser mesclada na Master|Main e Development.
• Release — Esta branch prepara novas alterações que vão levar a uma nova versão do que está em Produção. Permitindo assim que bugs menores sejam corrigidos. Ela pode se derivar da branch de development e tem como destino final ser mesclada na Master|Main e Development.

Vantagens

• Garante branches limpas em qualquer momento do ciclo de vida do projeto
• A nomenclatura das branches segue um padrão sistemático de nomes facilitando a compreensão
• Possui extensões e suporte nas IDEs mais usadas até o momento
• É ideal quando há necessidade de várias versões do mesmo produto/software em produção

Desvantagens

• O histórico do Git fica difícil de ler
• O split da Master|Main e develop fica redundante em certos casos dificultanto a vida do CI (Continuous Integration)
• Não é recomendado quando se precisa ter uma versão única de produto/projeto em produção

GitHub Flow

Criado pelo GitHub em 2011, possui 6 princípios:

1. Tudo que estiver na branch Master|Main é possível de se implementar
2. Para um novo repositório, crie uma branch a partir da Master|Main e e coloque um nome descritivo, exemplo: novo-app-xyz
3. Comprometa-se com esta branch local e e atualize regularmente utilizando a mesma origem
4. Quando você precisar de feedback ou ajuda, ou achar que a branch está pronta para merge, abra uma pull request
5. Só prossiga com o _merge) do seu trabalho depois que outra pessoa revisar a PR (pull request)
6. Depois que a merge for realizada na Master|Main, você deve realizar o deploy imediato

Vantagens

• E amigável com o CI/CD (Continuous Integration, Continuous Delivery)
• Uma alternativa para o Git Flow
• Ideal para versões únicas em produção

Desvantagens

• O código na Master|Main pode apresentar instabilidade mais facilmente
• Não é adequado para Release Plans
• Não suporta deploy, environments, releases, versions, problems e issues em seu formato
• Não é recomendado quando precisa-se de várias versões em produção

GitLab Flow

O GitLab Flow é um fluxo criado pelo GitLab em 2014. Ele combina o modelo de desenvolvimento feature-driven e feature-branch com issue tracking. A maior diferença entre o GitLab Flow e o GitHub Flow são as branches de ambiente, por exemplo: staging e production, porque nem sempre será possível realizar merge em produção, como nos casos de aplicações SaaS, PaaS e Apps Mobile.

O fluxo do GitLab é baseado em 11 regras:

1. Use Feature Branches, sem commits diretos no Master|Main
2. Teste todos os commits, não apenas os do Master|Main
3. Execute todos os testes em todos os commits (se seus testes durarem mais de 5 minutos, execute-os em paralelo).
4. Execute revisões de código antes antes do merge na Master|Main, não depois.
5. As implantações são automáticas, com base em branches ou tags.
6. As tags são definidas pelo usuário, não pelo CI.
7. Releases são baseados em tags.
8. Os commits enviados nunca são Rebased.
9. Todos começam a partir da Master|Main e têm como alvo Master|Main.
10. Corrija os bugs no Master|Main primeiro e libere os branches depois.
11. As mensagens de commit precisam ter significado.

Vantagens

• Define como fazer CI/CD de maneira apropriada
• O histórico do git será mais limpo, menos confuso e mais legível
• É ideal quando precisa-se de versão única em produção

Desvantagens

• É mais complexo que o GitHub Flow
• Pode se tornar complexo como o Git Flow, se for preciso manter várias versões em produção

Git One Flow

O One Flow é uma alternativa proposta no artigo GitFlow, por Adam Ruka, escrito em 2015. A principal condição que precisa ser satisfeita para usar o OneFlow é que cada nova versão de produção seja baseada na versão anterior. A maior diferença entre o One Flow e o Git Flow é que ele não possui a branch de desenvolvimento.

Vantagens

• O histórico do git será mais limpo, menos confuso e mais legível
• É flexível de acordo com as decisões do time
• É ideal quando precisa de versão única em produção

Desvantagens

• Não é recomendado para projetos com Continuous Delivery ou Continuous Deploy.
• As Feature Branches tornam difícil a vida do CI (Continuous Integration)
• Não é recomendado quando se precisa manter uma versão única em produção

Conclusão

E se você chegou até aqui….

cya! 🎶🎶🎶