Como é o seu processo de documentação de versões de software? Para tirar o melhor proveito do GIT é importante conhecer o que é Git Workflow e seus diferentes tipos. Assim, você conseguirá escolher o que melhor se aplica às suas necessidades!
Afinal, o que é Git Workflow?
Quando falamos de Git Workflow é normal que já venha a associação com a ferramenta GitHub ou GitLab, mas são coisas diferentes. O Git é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo.
O Git Workflow é uma receita ou recomendação de como usar o Git para realizar o trabalho de maneira consistente e produtiva. Há vários Git Workflows divulgados que podem ser uma boa opção para sua equipe.
Neste artigo vamos falar sobre três tipos de Git Workflows, são eles:
- GitHub Flow;
- Git Flow;
- GitLab Flow.
Está começando a mexer no Git? Então o artigo “Git, Github e Gitlab: o que são e principais diferenças” é para você!
GitHub Flow
O GitHub Flow foi criado pelo GitHub em 2011 e é o modelo mais simples de Git Workflow.
Ele é um fluxo de trabalho baseado em Branchs onde as implantações são feitas regularmente. Cada unidade de trabalho, seja um bug ou feature, é feita através de uma branch criada a partir da main. Depois que o trabalho é concluído na branch, ele é revisado e testado antes de realizar o merge na main e enviado à produção.
A branch de suporte já é bem conhecida pelos usuários do Github. Antes do merge com a branch principal, na branch de suporte, o código é revisado e testado.
Detalhamento da Branch de suporte
Git Flow
O Git Flow foi desenvolvido em 2010 pelo engenheiro de software holandês, Vincent Driessen. O Git Flow define um modelo de branchs rigoroso projetado com base em releases. Isso oferece uma estrutura robusta para gerenciar projetos maiores. Este fluxo é ideal para projetos que possuem um ciclo de entrega agendada.
O Git Flow trabalha com dois branchs principais, a Develop e Main, que duram para sempre e quatro branchs de suporte, Feature, Release, Bugfix e Hotfix, que duram até realizar o merge com as branchs principais.
Como as branchs principais são fixas, elas devem sempre estar sincronizadas. Já as branchs de suporte, que tem tempo de vida definido, devem ser excluídas assim que o merge for realizado nas branchs principais.
Abaixo segue o detalhamento de cada Branch
Branch principal:
- Main: Aqui é onde temos todo o código de produção. Todas as novas funcionalidades que estamos desenvolvendo, em algum momento, serão mescladas ou associadas a Main.
- Develop: Aqui é onde fica o código do nosso próximo deploy. Isso significa que, como recursos ou funcionalidades, será finalizado e adicionado nesta ramificação para posteriormente passar por mais uma etapa antes de ser associado a uma Main.
Branches de suporte:
- Feature – são branches para o desenvolvimento de uma funcionalidade específica. Elas devem ter o nome iniciado por feature, por exemplo, “feature / payment-system”. É importante saber que essas features branches são criadas sempre a partir da branch Develop. Portanto, quando finalizada, ela é removida após realizar o merge com a Branch Develop.
- Release – Serve como ponte para fazer o merge da Develop para a Main. Funciona como ambiente de homologação e é removida após realizar os testes e do merge com a Main. Caso haja alguma alteração, ela também deve ser sincronizada com a Develop.
- Bugfix – Uma branch criada a partir da Release para realizar correções encontradas no sistema ainda no momento desenvolvimento, Quando concluída ela é excluída após realizar o merge com a Branch Release.
- Hotfix – Uma branch criada a partir da Main para realizar correções encontradas no sistema em produção. Quando concluída ela é excluída após realizar o merge com a Branch Main e Develop.
GitLab Flow
O GitLab Flow é um fluxo de trabalho criado pelo GitLab em 2014.
A diferença do GitLab Flow para o Git Flow é que ele possui três branchs principais ao invés de dois. Os nomes das branchs mudam um pouco, mas eles são definidos pela equipe, ou seja, não é uma regra utilizar os nomes do exemplo.
Esse é o fluxo de trabalho ideal para organizações que precisam liberar novas funcionalidades com frequência, em vez de ter releases agendadas. Ele tenta manter as vantagens de ter um fluxo mais simples do GitHub Flow e as linhas de integração que acompanham o Git Flow. Possui três Branchs principais que duram para sempre e três Branchs de suporte que duram até realizar o merge.
Abaixo segue o detalhamento de cada Branch:
Branch principal:
- Main (Dev);
- Staging (Homologação);
- Production (Produção);
Branches de suporte (Temporárias)
- Feature – Branch com novas funcionalidades. Quando finalizada, ela é removida após realizar o merge com a Branch Main.
- Bug Fix: Uma branch criada a partir da Staging para realizar correções e no final ela faz o merge na Staging e na Main. A branch é removida após realizar o merge.
- Hotfix – Uma branch criada a partir da Production para realizar correções e no final ela faz o merge diretamente na Staging e Production. A branch é removida após realizar o merge.
Pontos Positivos e Negativos de cada Git Workflow
Tudo na vida tem prós e contras. Por isso, tenha atenção nas vantagens e desafios de cada git workflow que a gente abordou até agora. Destaco esses pontos:
Pontos Positivos
Uma das vantagens do Git Flow e do GitLab Flow é o controle rigoroso. Somente desenvolvedores autorizados podem aprovar alterações depois de analisá-las de perto. Eles garantem a qualidade do código e ajudam a eliminar erros antecipadamente.
O Git Flow e o GitLab Flow são indicados quando você:
- executa um projeto de código aberto.
- tem muitos desenvolvedores atuando no projeto.
- tiver um produto estabelecido.
Pontos Negativos
Git Flow e do GitLab Flow criam um funil que desacelera o desenvolvimento de software. Se a velocidade é sua principal preocupação, isso pode ser um problema sério. Os recursos desenvolvidos separadamente podem criar branches longas que podem ser difíceis para realizar o merge no projeto principal.
O Git Flow e o GitLab Flow não são indicados quando você:
- está apenas começando.
- precisa liberar rapidamente.
- tem poucos desenvolvedores no projeto.
Problemas que você pode encontrar utilizando esses fluxos:
- Muitas Branches – A administração das branches começa a ficar complicada.
- Branches desatualizadas – O time pode esquecer de atualizar as branches. Isso gera muitos problemas e retrabalho.
- Os nomes utilizados nas branches podem confundir.
Dicas para trabalhar com Git Workflow
Acredite, para cada tipo de trabalho tem um tipo de Git Workflow ideal! Dúvida? Então acompanhe algumas situações a seguir:
1- Versão única de um software simples em produção
Se o seu código tiver apenas uma versão em produção o tempo todo (por exemplo, sites, serviços da web etc.), você poderá usar o GitHub Flow. O principal motivo é que você não precisa fazer coisas complexas para o time de desenvolvimento. Depois que o time termina um recurso ou corrige um bug, ele é imediatamente promovido para a versão de produção.
Resumindo: software simples, equipe de desenvolvimento pequena e poucas interações? Então use o GitHub Flow.
2 – Várias versões em produção
Se o seu código tiver várias versões em produção (por exemplo, produtos de software típicos como sistemas operacionais, pacotes do Office, aplicativos personalizados etc.), você poderá usar o Git Flow. O principal motivo é que você precisa oferecer suporte contínuo a versões anteriores em produção enquanto desenvolve a próxima versão.
Resumindo: precisar oferecer suporte a versões anteriores? Então, use Git Flow.
3 – Versão única em produção, mas software muito complexo
Para softwares grandes como, por exemplo, o Facebook e o Gmail, pode ser necessário introduzir branch de deploy entre a branch staging e a branch principal, onde as ferramentas de CI / CD poderiam ser executadas antes de entrar em produção.
A ideia é introduzir mais proteção na versão de produção, já que é usada por milhões de pessoas.
Resumindo: software complexo, grande equipe de desenvolvedores e não precisa dar suporte a versões anteriores? Então use o GitLab Flow.
Exemplos
Agora vou mostrar três exemplos de uso de Git Workflows. Para isso vou utilizar o seguinte cenário:
Cenário:
1 – Uma Branch já rodando em Produção, precisando urgente da correção de 15 Bugs.
2 – Uma Branch “A”, com Sprint rodando e data de entrega em Produção marcada para 10/07/2020.
3 – Uma Branch “B” derivada de “A” depois do desenvolvimento da Branch “A”, com funcionalidades que não poderão entrar em 10/07/2020, com entrega marcada em Produção para 20/07/2020.
4 – Surge uma demanda emergencial, com a entrega em Produção marcada para 01/07/2020.
5 – São detectados BUGs da Branch “A” nos testes de “B”.
Exemplo 1 – WorkFlow com Bug não crítico
1 – Branch Main recebendo as correções pelas branchs “Hotfix”
2 – Branch Feature A recebendo uma atualização da branch Develop antes de realizar o merge, pois houveram alterações em Develop devido aos Hotfix’s e inclusão da feature emergencial
3 – Branch “Feature B” sendo criada após o merge da Feature A na branch Develop
4 – Branch Feature Emergencial, criada junto com a Feature A, recebe atualização da branch Develop antes de realizar o merge.
5 – Branch de release, criada a partir da Develop, recebe uma atualização da branch Bugfix e realiza o merge nas branchs Develop e Main.
Neste exemplo é possível visualizar como é feita a correção de um bug não crítico. A branch BugFix é criada a partir da Release e após a correção e teste, é feito o merge com a branch de Release e em seguida a branch BugFix é excluída. Na entrega da Release, ela é sincronizada com as branchs Develop e Main.
Mas se esse fosse um bug crítico? Então neste caso o desenho ficaria conforme o exemplo 2:
Exemplo 2 – WorkFlow com bug crítico
A diferença deste exemplo para o anterior é o item 5, que mostra como o bug encontrado foi tratado.
O bug encontrado é crítico. Por isso, a branch Hotfix é criada a partir da Main e após a correção e teste, é feito o merge com as branchs Release e Main.
Nos dois exemplos podemos notar que as branchs principais (Main e Develop) sempre se mantêm sincronizadas, para evitar que bugs corrigidos anteriormente não voltem aparecer.
Exemplo 3 – WorkFlow – Problemas com o sincronismo de Branch principal
Este exemplo mostra um problema que acontece no dia a dia do desenvolvimento. Quando você esquece de sincronizar as branchs principais, a entrega começa a falhar.
Observe o desenho abaixo:
Neste exemplo, o hotfix de cinco bugs não foi sincronizado com a branch Develop, quando a Release emergencial foi entregue. Assim, os bugs retornaram para produção, gerando retrabalho, custo, perda de credibilidade e insatisfação do cliente. Parece um absurdo, mas isso acontece com muita frequência.
Conclusão
Esses são alguns exemplos de Git Workflows mais conhecidos e existem muitos outros que podem ser aplicados.
Crie um workflow que atenda bem o projeto e as necessidades da equipe, não se prenda a regras muito elaboradas e complexas, isso só vai gerar dúvidas.
Usar uma abordagem GitHub Flow ou GitLab Flow pode não funcionar. O mais importante é que a equipe como um todo entenda o fluxo de trabalho e mantenha esse fluxo consistente.
Comece com um modelo o mais simples possível (como o fluxo do GitHub costuma ser) e, se necessário, avance para um mais complexo.
Os workflows não são fixos, podem ser alterados de acordo com a necessidade do projeto. GitFlow funciona bem quando há releases com um período maior (a cada 2 semanas, por exemplo). Quando há releases diárias ou mais de uma vez por dia, esse processo falha.
E você, como faz no seu time? Conta para a gente nos comentários!
Referências:
- A successful Git branching model.
- Trunk-based Development vs. Git Flow.
- Guide to a better git flow for automated environments.
- Git: How I use it and Why I don’t use GitFlow.
- What are the pros and cons of git-flow vs github-flow?
- Resumo GitFlow e alguns comandos.
- Versionamento Semântico.
- Git
- Vincent Driessen – A successful Git branching model.
- Gitlab Docs – Introduction to GitLab Flow.
- Atlassian BitBucket – Gitflow Workflow.
- Scott Chacon – GitHub Flow.
- Git Flow na prática.
- Understanding the GitHub Flow.
- Git Flow // Dicionário do Programador.
- GitLab – The new Git default branch name
- Sempre Update – GitHub substituirá ‘master’ por ‘main’
