Git Workflow: o que é e principais tipos

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:

  1. GitHub Flow;
  2. Git Flow;
  3. 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.

Descrição da imagem:
Branch Main, representada por uma linha horizontal continua.
Branch Bugfix, é uma branch de suporte, representada por uma linha horizontal ramificada da branch Main. Esta linha se mescla novamente com a Main apos conclusão do trabalho de desenvolvimento.
Branch Feature, é uma branch de suporte, representada por uma linha horizontal ramificada da branch Main. Esta linha se mescla novamente com a Main  apos conclusão do trabalho de desenvolvimento.
Fonte

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

Detalhamento da Branch de suporte
1 - Momento de criação da branch de suporte
2 - Commits realizados na branch de suporte
3 - Abertura de pull request para merge na main
4 - Review
5 - Testes
6 - Merge com a branch main.
Fonte


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.

Figura Git Flow
Branch Develop: Representada por uma linha horizontal que contem circulos na cor azul em cima desta linha. Cada circulo representa uma interação realizada na branch, geralmente um merge vindo das branchs de suporte.
Branch Feature, representada por uma linha horizontal ramificada da branch Develop. As interações desta branch são representadas por circulos na cor Branca, ao final das interações, ela se mescla com a branch Develop.
Branch de Release: Representada por uma linha horizontal ramificada da branch Develop. As interações desta branch são representadas por circulos na cor vermelha.A o final das interações, ela se mescla com a branch Master e Develop.
Branch Release-Bugfix: Representada por uma linha horizontal ramificada da branch Release. As interações desta branch são representadas por circulos na cor Amarela. Ao final das interações, ela se mescla com a branch Release
Branch Main: Representada por uma linha horizontal com interações representadas por circulos na cor laranja. As branchs de Release e HotFix se mesclam a ela.
Branch Hotfix: Representada por uma linha horizontal ramificada da branch Main. As interações desta branch são representadas por circulos na cor roxa. Ao final das interações, ela se mescla com a branch Main
Fonte


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.

Figura GitLab Flow
Branch Main: Representada por uma linha horizontal que contem circulos na cor azul em cima desta linha. Cada circulo representa uma interação realizada na branch, geralmente um merge vindo das branchs de suporte.
Branch Feature, representada por uma linha horizontal ramificada da branch Main. As interações desta branch são representadas por circulos na cor Verde, ao final das interações, ela se mescla com a branch Main.
Branch Staging: Representada por uma linha horizontal ramificada da branch Main. As interações desta branch são representadas por circulos na cor vermelha.A o final das interações, ela se mescla com a branch Production e Main.
Branch Bugfix: Representada por uma linha horizontal ramificada da branch Staging. As interações desta branch são representadas por circulos na cor Amarela. Ao final das interações, ela se mescla com a branch Staging e Main
Branch Production: Representada por uma linha horizontal com interações representadas por circulos na cor laranja. As branchs de Staging e HotFix se mesclam a ela.
Branch Hotfix: Representada por uma linha horizontal ramificada da branch Production. As interações desta branch são representadas por circulos na cor Amarela. Ao final das interações, ela se mescla com a branch Production e Staging

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

Exemplo do Git Workflow, WorkFlow com Bug não crítico. Está detalhado abaixo.

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.

Exemplo do Git Workflow, WorkFlow com Bug crítico. Está detalhado abaixo.

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:

Exemplo do Git Workflow,  Problemas com o sincronismo de Branch principal. Está detalhado 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:

Capa do artigo Git Workflow
Foto de Flavio Antunes
Quality Assurance Analyst
Pós Graduado em Engenharia de Qualidade de Software. Apaixonado por tecnologia, qualidade de software e aprendendo a compartilhar conhecimento.

This website uses cookies to ensure you get the best experience on our website. Learn more