Gitflow: entenda quando e como você deve utilizar

Time Lumis

Publicado 01/01/2025 3 min leitura

Ao utilizar o Git para gerenciar versões de um projeto é preciso decidir o fluxo de trabalho (workflow), que irá estabelecer funções bem específicas para diferentes branches e definir quando elas devem interagir. Existem diversos fluxos de trabalhos consolidados e que podem ser utilizados nos projetos. Vale ressaltar que não existe um fluxo de trabalho perfeito onde todos devam seguir, você deve decidir o modelo com base principalmente nas características de implantação do seu projeto. Neste artigo será abordado o fluxo de trabalho chamado Gitflow, criado por Vincent Driessen.

Antes de definir utilizar este modelo em seu projeto é extremamente importante você ter pleno entendimento de quais situações é recomendado o uso do Gitflow. É comum as pessoas acharem que o Gitflow é um padrão que pode ser estabelecido em qualquer projeto que utilize Git, o que não é uma verdade. Você pode ter sérios problemas como limitar a velocidade de entrega e dependências entre features quando este modelo é utilizado em cenários que não são recomendados.

Quando utilizar?

O Gitflow é recomendado e estimulado para projetos que utilizam versionamento semântico (semantic versioning) ou precisam oferecer suporte a várias versões de seu software. Segundo o próprio autor Vincent Driessen, se o projeto exige entrega contínua, como normalmente ocorre em projetos de aplicativos da WEB, este modelo não é recomendado para esse tipo de cenário. Isso porque geralmente na prática, é gerado branches de longa duração que este fluxo favorece. E branches de longa duração atrapalham a entrega contínua, pois é comum gerar os famosos "merge hell" em que exigirá tempo de uma pessoa para resolução de conflitos.

Uma nota foi publicada em 5 de março de 2020 no mesmo artigo em que o autor publicou sobre este modelo. Vale destacar a seguinte parte "...If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team...". O artigo pode ser visualizado em referências / item 2.

Como utilizar?

Branches básicas

O Gitflow inicia com as seguintes branches básicas

Master: contém o código-fonte de produção já testado

Develop: contém o código-fonte mais atual incluindo tudo que já foi desenvolvido até o momento (features + hotfix)

https://www.atlassian.com/br/git/tutorials/comparing-workflows/gitflow-workflow

Branches de suporte

A partir das branches básicas são criadas as branches de suporte. As branches de suporte são do tipo feature, hotfix ou release. A imagem abaixo, ilustra a origem para cada tipo de branch e o destino.

Feature branches são ramos para desenvolvimento de recursos do sistema, criados a partir da branch develop. Após o desenvolvimento retornam para branch develop através de merge.

Hotfix (correções emergenciais) são branches criadas a partir da master, e o(s) commit(s) são realizados nesse ramo e em seguida deve ser realizado um procedimento de merge em direção a branch master (origem) e develop, para que a correção esteja disponível para as novas features.

Release branches são utilizadas para preparação do lançamento da próxima versão de produção. São criadas a partir da develop e devem ser mescladas em direção a develop e a master. O merge na develop é importante, pois atualizações críticas podem ter sido adicionadas a release branch e precisam estar acessíveis a novos recursos.

As branches master e develop são linhas contínuas, ou seja, se mantém durante todo o tempo de projeto.

As branches de suporte são temporárias, após concluir seu propósito e retornar para a origem devem ser descartadas.

Não há merge da develop em direção a master diretamente, sempre utiliza-se as release branches.

As branches que realizam merge em direção a master devem gerar tags.

Praticando

Existem ferramentas para auxiliar no dia a dia quanto a este modelo, você não precisará se preocupar com a origem a qual a nova branch será criada, para onde deve ocorrer o merge quando o trabalho for concluído e se é necessário criar tag. A ferramenta irá gerenciar isso para você. Neste artigo será apresentado uma extensão para linha de comando, como é uma extensão, tal recurso não é instalado nativamente com a instalação do Git. Considere o link abaixo e as orientações para realizar a instalação:

https://github.com/nvie/gitflow/wiki/Installation

Após a instalação:

Crie um diretório em seu computador com o nome "gitflow";
Acesse tal pasta utilizando o Git Bash;
Execute: git flow init;
Altere os prefixos se preferir ou pressione enter para cada interação para manter o padrão.

Note que se você executar git branch será exibido inicialmente as branches master e develop.

Criando uma feature branch

Para iniciar o desenvolvimento em uma nova feature basta executar o comando abaixo:

git flow feature start <NOME_FEATURE>

Note que denominamos a feature com o nome cache-provider e tal nome foi concatenado com o prefixo definido para este tipo. As ações internas envolveram criar uma nova branch baseada na develop e um checkout em tal branch.

Para demonstração do desenvolvimento da feature hipotética execute os seguintes passos:

touch cache-provider.js (cria um arquivo em branco chamado cache-provider.js no diretório Git);
git add cache-provider.js (adiciona o arquivo na área de preparo/staging para o próximo commit);
git commit -m "adding a cache provider" (realiza um commit que inclui o arquivo recém criado);
git flow feature finish <NOME_FEATURE> (indica que a feature foi concluída e pode ser "mergeada" para develop).

Como visto na imagem acima, também não é necessário informar o prefixo na hora de encerrar a feature. Ao concluir uma feature as ações internas que ocorrem são: merge da feature em direção a develop, remoção da branch criada feature/cache-provider e checkout na na branch develop. Caso você estivesse desenvolvendo uma nova feature colaborativamente, seria interessante após cada commit você publicar a feature da seguinte forma: git flow feature publish <NOME_FEATURE>

Criando uma hotfix branch

Quando um problema emergencial surge que não se pode esperar a próxima release então pode-se utilizar hotfix. Para isso, basta executar o seguinte comando:

git flow hotfix start <NOME_HOTFIX>

É importante observar que este tipo de branch foi criado baseado na master. Logo após criar a branch é feito um checkout na recém criada branch.

Para demonstração do desenvolvimento da hotfix hipotética execute os seguintes passos:

touch template-fix.js
git add template-fix.js
git commit -m "template bug fix"
git flow hotfix finish template-fix

Será aberto o editor padrão para solicitar uma definição da tag e do commit de merge. Você deve informar obrigatoriamente ambas as descrições (a descrição do merge já possui uma definição padrão que você pode manter, mas a tag não).

Observe que várias ações aqui foram promovidas: houve um merge da branch hotfix tanto em direção a master como da develop, uma tag foi criada, a branch de hotfix foi deletada e houve um checkout novamente para a branch develop.

Criando uma release branch

A correção emergencial já consta nas duas branches principais, contudo nossa feature ainda não está na master. Para promover a feature na branch master deve-se criar uma release branch. Para isso execute o comando abaixo:

git flow release start <NOME_RELEASE>

Neste momento, foi realizado checkout na branch do tipo release que foi criada a partir da branch develop. Esta branch permite correções antes de ser mesclado na master, o que justifica um merge de volta para develop. Não será realizado nenhum tipo de correção, por isso basta executar:

git flow release finish <NOME_RELEASE>

Note neste momento que um merge foi realizado em direção a master e a develop, uma tag foi criada, a branch release foi deletada e um checkout foi realizado para a branch develop.

Guia

A imagem abaixo ilustra bem como você pode utilizar esta extensão para Gitflow por linha de comando.

https://danielkummer.github.io/git-flow-cheatsheet/index.pt_BR.html

Conclusão:

Este artigo foi abordado de forma teórica e prática com o intuito de gerar uma reflexão quanto a correta utilização do Gitflow e apresentar uma extensão ao Git que auxilia na implementação deste modelo. Como dito, existem diversos fluxos de trabalho e você deve sempre avaliar o contexto de cada projeto para decidir qual fluxo mais se encaixa para cada situação.

Referências

Valéria Sampaio

Gitflow: entenda quando e como você deve utilizar

Time Lumis

Quando utilizar?

Como utilizar?

Praticando

Você também vai gostar de ler

Receba conteúdos exclusivos

Um pouco do nosso conteúdo