top of page
Blog SO Labs na Íntegra
Writer's pictureDaniel Sanches

Git Flow - Fluxo e Processos


Caso você já conheça o Git, provavelmente já ouviu falar sobre o Git Flow. Nele temos um fluxo de trabalho fácil e com novos tipos de comandos para cada ação do seu projeto, seja incluir uma nova funcionalidade, corrigir um simples bug ou até mesmo o etiquetamento de uma nova versão.

Concebido num pequeno blog em meados de 2010, o Git Flow vem ganhando muita força desde então. Assim, é essencial que quem já trabalha na área conheça essa ferramenta que ajuda tanto na estruturação e desenvolvimento com o Git.



Por isso, neste artigo mostraremos para você tudo sobre o Git Flow. Além de exemplos práticos, veremos os seus principais comandos, vantagens e como é feito a instalação dessa ferramenta na sua máquina. Boa leitura!


O que é Git Flow?


É um fluxo de trabalho para o Git criado para facilitar o processo de desenvolvimento com uma série de comandos novos. O nome por trás desse modelo é Vincent Driessen que, em 2010, escreveu em seu blog pessoal a maneira que ele pensou ser a mais simples de se trabalhar com o Git em larga escala.


Mesmo sendo um método que auxilia o nosso trabalho devemos ter algumas ressalvas diante de como é aplicado: se usado de maneira inadequada, o Git Flow pode se tornar bastante ineficiente e gerar uma experiência não muito agradável.


Além disso, existe um repositório no GitHub onde podemos ver o código aberto do modelo criado. O código em si é feito todo em Shell e o commit mais recente foi de 2012 (muito tempo atrás, né).


Na imagem a seguir, vemos a estrutura de como é o fluxo do Git Flow:



Como funciona e quais os branches do fluxo Git Flow?


O primeiro passo para entender o Git Flow é compreender o funcionamento das branches (ramos) que são estabelecidas por padrão. Com elas, além de conseguirmos uma nomenclatura simples e arranjada, temos a categorização que as torna mais objetivas e de fácil entendimento para pessoas de fora do projeto.


1. Branch Main/Master

Principal branch, contém associadas a ela as versões de publicação para facilitar o acesso e a busca por versões mais antigas. Também entendemos que é o espelho do programa que está no ar, já que o último código dessa branch deve sempre estar em produção. Além do mais, a única maneira de interagir com essa branch é através de uma Hotfix ou de uma nova Release.


2. Branch Develop

É uma das principais branches e serve como uma linha com os últimos desenvolvimentos. Como visto na imagem, é uma cópia da branch principal contendo algumas funcionalidades que ainda não foram publicadas. Sendo assim, é a base para o desenvolvimento de novas features.


3. Branch Feature

Uma das branches temporárias e auxiliares do nosso fluxo, sendo a branch que contém uma nova funcionalidade específica para a nossa aplicação. Nela temos a convenção do nome feature/nome_do_recurso que será utilizada no nosso fluxo de trabalho. Não podemos esquecer que toda nova Feature começa e termina obrigatoriamente a partir da develop.


4. Branch Hotflix

Também é uma branch auxiliar e temporária, utilizada quando ocorre algum problema no ambiente de produção no qual a correção deve ser feita imediatamente. Conseguimos com isso solucionar o erro e fazer a mesclagem da solução para as branches main/master e develop para que não ocorra a perda do nosso código.


5. Branch Release

Por fim, a branch de lançamento do nosso programa. Nela unimos o que está pronto em nossa branch de desenvolvimento e “jogamos” para a branch principal. No mais, é criado uma nova versão etiquetada no nosso projeto para que possamos ter um histórico completo do desenvolvimento.


Como funciona e quais os branches do fluxo Git Flow?


Chegou o momento de praticar um pouco o que vimos até agora, e com bastante calma para que você possa entender A seguir, vamos olhar os principais comandos do Git Flow, desde a inicialização até o momento de subida para o ambiente em produção. Para que você consiga acompanhar corretamente essa parte, é recomendável que você tenha algum conhecimento básico dos comandos Linux ou até mesmo os comandos CMD do Windows:


Init

É o comando inicial do Git Flow e serve para configurar o repositório com as branches do fluxo padrão. Da mesma forma que você tem que inicializar o git em um novo diretório, esse comando tem o mesmo propósito.


Feature

Dentro desse comando temos algumas ramificações possíveis, como por exemplo:

start nome_feature  

Comando que inicia uma nova feature, nela temos a criação de uma branch com a nomenclatura feature/nome_feature.

finish nome_feature  

Comando para encerrar uma feature anteriormente criada, além disso será feito um merge para a branch Develop.

publish nome_feature  

Se você está trabalhando em equipe e deseja compartilhar a sua nova funcionalidade, esse comando publica no servidor remoto que está configurado no seu Git local.

pull nome_feature 

Ao contrário da anterior, essa serve para obter uma feature do servidor remoto.


Release

Com a terminologia parecida, veremos os comandos referentes ao lançamento:

start nome_release [BASE]  

Utilize esse comando para iniciar uma versão baseada na branch de desenvolvimento, aqui você pode passar opcionalmente o código de algum commit para usar como base.

publish nome_release

É aconselhável publicar a branch de release após criá-la para permitir commits de outras pessoas desenvolvedoras. O comando é semelhante à publicação de uma nova feature.

release track nome_release  

Novamente, se você quiser acompanhar alguma versão remota da release, existe esse comando.

finish nome_release

Com esse comando você finaliza e cria uma nova versão, logo em seguida é executada uma série de ações:

  • junta a branch na Main/Master;

  • cria uma tag com o nome da branch;

  • também junta a branch com a Develop;

  • por último, apaga a própria branch.


Hotflix

Por fim temos os comandos da Hotfix:

hotfix start nome_hotfix [BASENAME]

A partir do último commit da branch Main/Master cria-se uma branch com a nomenclatura de hotfix/nome_hotfix. É obrigatório que seja passado o nome da hotfix e opcionalmente você pode passar um BASENAME.

hotfix finish nome_hotfix

Temos novamente o comando para a finalização da hotfix. Quando terminado o processo final vemos que é feito uma mesclagem da hotfix nas branches main/master e develop e também temos a criação de uma etiqueta na main/master.


Instalando o Git Flow?


Atualmente, o Git Flow já vem incluso nas últimas versões do Git e você consegue baixar o Git em qualquer sistema operacional moderno. No entanto, existem algumas formas de baixar apenas o Git Flow:


Linux

No Linux temos uma infinidade de sistemas operacionais. Sendo assim, vamos tentar deixar o máximo de comandos possíveis:


Debian
apt-get install git-flow
Archilinux
yay -S gitflow-avh
Fedora
sudo dnf install gitflow
Gentoo
emerge --ask git-flow
FreeBSD
pkg install gitflow

Se mesmo assim você não conseguiu instalar, tente usar esses comandos:

curl -OL https://raw.github.com/nvie/gitflow/develop/contrib/gitflow-installer.sh
chmod +x gitflow-installer.sh
sudo ./gitflow-installer.sh

Mac

Também temos bastantes opções nesse caso, como:


Homebrew
brew install git-flow

MacPorts
port install git-flow
Wget
wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash
Curl
curl -L -O https://raw.github.com/nvie/gitflow/develop/contrib/gitflow-installer.sh sudo bash gitflow-installer.sh

Windows

Chegando ao fim temos essa opção:


Cygwin
wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

Entendendo o Git Flow com exemplos práticos


Agora que instalamos e sabemos o básico sobre esse fluxo, vamos dar uma olhada em alguns exemplos com o Git Flow:


Criando o repositório


Primeiramente vamos criar um repositório para que possamos executar os nossos testes.

mkdir teste-git-flow // Cria uma nova pasta com o nome “teste-git-flow”
cd teste-git-flow  // Entra na pasta que foi criada
git init      // Inicia o repositório


Iniciando o Git Flow


Já na pasta criada devemos rodar o comando de inicialização:


git flow init

Aparecerá uma série de questões referentes às nomenclaturas das branches e algumas configurações. No momento, recomendamos que você apenas aperte enter em todas as linhas:



Além de criar toda a estrutura para o nosso repositório, o comando também já faz o checkout para a branch Develop.


Feature


Iniciando uma nova feature


Imagine que estamos desenvolvendo uma tela de cadastro e que queremos separar o nosso desenvolvimento da branch principal. Com isso, criamos uma nova feature:

git flow feature start tela-cadastro

Para o nosso teste, vamos criar um arquivo HTML e fazer um commit:

touch tela-cadastro.html        // Criando arquivo html
git add .                // Adicionando arquivo criado
git commit -m "Criando tela de cadastro" // Fazendo commit

Terminando a feature


Já que finalizamos o desenvolvimento, vamos agora rodar o comando para fechar essa branch e mesclá-la com a develop:

git flow feature finish tela-cadastro

Como podemos ver, algumas ações foram feitas:

  • merge da feature para a develop;

  • a nossa branch da feature foi deletada;

  • foi feito o checkout para a develop.


Release


Iniciando uma release


Vamos agora simular uma release com o nome de “release-teste”:

git flow release start release-teste

Podemos ver que foi criado uma branch e que automaticamente fomos redirecionados para ela.


Finalizando uma release


Vamos agora finalizar a nossa release:


git flow release finish release-teste 1.0.0

Quando o comando for executado vai aparecer uma tela parecida com essa. Não se assuste, é apenas um programa chamado Vim que é um editor de texto para o terminal. Para prosseguirmos com o nosso tutorial, siga os próximos passos:


  • aperte a tecla i e escreva uma mensagem, no meu caso vou escrever “finalizando”.

  • em seguida aperte Esc e digite o comando :wq para salvar e fechar o Vim.



Como podemos ver foram feitas várias ações no nosso repositório, tais como:

  • a mesclagem da nossa branch de release para main/master e develop;

  • criação da tag “release-teste” na main/master;

  • remoção da nossa branch de release;

  • checkout para a branch develop.

Com muita facilidade conseguimos finalizar e criar uma nova versão para o nosso projeto de testes.


Hotfix


Iniciando uma hotfix


Vamos partir para mais uma demonstração. Primeiramente execute o comando de início de uma nova hotfix:


git flow hotfix start hotfix-teste


Semelhant

e aos outros comandos, é criado para a gente uma nova branch com o nome que passamos. Além disso, somos realocados para ela.


Novamente, para fins de teste, vou criar um novo arquivo JavaScript simulando uma correção.


touch arquivo-correcao.js   // Criando arquivo JavaScript
git add .           // Adicionando arquivo criado
git commit -m "Correção do bug" // Fazendo commit

Finalizando uma hotfix


Vamos agora finalizar a nossa correção:


git flow hotfix start hotfix-teste


Novamente nos deparamos com a tela do Vim, porém, agora já estamos experientes com essa situação. Relembrando, aperte a tecla i e escreva uma mensagem. Logo em seguida aperte Esc e escreva :wq.



O processo de finalização de uma hotfix é muito semelhante ao de uma release. Com isso, temos o merge da nossa branch com a main/master e develop. Também é criado uma etiqueta na main/master, é deletado a nossa branch de correção e, por último, somos levados para a develop.


__________________________________________________________________________________


Conclusão do Use Case


Quais as vantagens e desvantagens do Git Flow?


Como tudo na vida temos o lado ruim e o lado bom, isso também se aplica ao Git Flow e nessa parte mostraremos alguns pontos de atenção que devem ser levados em conta antes de tentar utilizar essa ferramenta.


Quais os benefícios do Git Flow


Os vários tipos de branches e nomenclaturas tornam o trabalho muito mais simples, intuitivo e fácil de organizar. Conseguimos testar eficientemente por causa do sistema de features e além disso versionamos múltiplas versões com extrema facilidade, apenas utilizando poucos comandos.

Uma das principais vantagens que notamos ao utilizar o Git Flow é o desenvolvimento em paralelo com o isolamento das novas funcionalidades que separamos do trabalho que já foi feito. Como comentado, o novo desenvolvimento (como as features ou até mesmo os bug-fixes) são feitos em branches separadas e mescladas de volta para as principais branches, tanto main/master como develop.


Temos também a parte da colaboração, em que podemos compartilhar com muita facilidade o nosso desenvolvimento com outras pessoas desenvolvedoras. Temos apenas que mandar a nossa branch de desenvolvimento para o servidor remoto onde qualquer pessoa consegue puxar e continuar o trabalho. Com isso, também conseguimos saber o que cada pessoa está fazendo no projeto.


Na estrutura do Git Flow conseguimos utilizar as chamadas hotfix para resolver problemas em produção rapidamente. Logo, conseguimos fazer o merge com as branches de main/master e develop, tornando assim muito claro a solução de um bug.


Por último, vale lembrar da Staging Area, que basicamente é a nossa branch develop que tem esse nome, pois como toda nova funcionalidade é criada e terminada a partir da develop, conseguimos ter um local onde podemos testar todas as nossas novas features, isso sem se preocupar se estamos ou não em produção.


Quais os principais problemas e desvantagens do Git Flow?


Vamos comentar agora sobre alguns pontos fracos do Git Flow. De cara podemos destacar que ele não é para todo mundo, ou seja, dependendo da complexidade do projeto que você está trabalhando, a estrutura do Git Flow pode tornar o processo muito complicado e o desenvolvimento mais lento.


Por causa do ciclo de desenvolvimento longo, o Git Flow não consegue se adaptar bem com o DevOps. Isso porque ele não consegue dar suporte à integração e implantação contínua, o que o torna totalmente obsoleto em alguns casos.


Por fim, podemos destacar que o fluxo e o processo em si são muito complexos. Apenas pense o quão complicado é tentar controlar um repositório onde temos alterações ocorrendo toda hora nas branches main/master e develop. Além do mais, temos muitos problemas específicos e corriqueiros nesse fluxo, pois temos várias branches sendo criadas em paralelo.



Conheça outros fluxos do Git


Mesmo o Git Flow sendo muito popular desde o seu início em 2010, devemos salientar que até o seu criador (Vincent Driessen) admite que essa estrutura pode não ser a melhor em todos os times de desenvolvimento. Ele fala um pouco sobre isso em uma nota de reflexão escrita em Março de 2020:


“Os aplicativos da web são normalmente entregues continuamente, não revertidos, e você não precisa oferecer suporte a várias versões do software em execução. Este não é o caso do software que eu tinha em mente…10 anos atrás”. Se você tiver interesse em ler o texto completo fique à vontade, essa foi apenas uma tradução rápida.


Atualmente temos dois modelos para Git que são mais simples e aceitam as famosas entregas contínuas.



GitHub Flow


Mais simples que o Git Flow, o Github Flow é perfeito para pequenos times e programas web ou projetos que não precisam de suporte para múltiplas versões. O GitHub Flow permite o bom uso da entrega contínua e integração contínua, tudo isso por causa da simplicidade que foi criado o modelo.


Obviamente temos alguns problemas para serem considerados. A falta de branches de desenvolvimento dedicado tornam todo o trabalho bem mais suscetível a bugs em produção.



GitLab Flow


Mais simplificado que o Git Flow, o GitLab Flow é mais organizado e melhor estruturado se comparamos com o Github Flow. Nele somos introduzidos em algumas branches de ambiente, como produção, pré-produção e até mesmo release, dependendo do caso.

Com algumas pequenas mudanças, o GitLab Flow permite o versionamento das versões e entrega contínua. Claramente temos os mesmos problemas do GitHub Flow nesse modelo.



One Flow


O One Flow é uma alternativa proposta por um post do Adam Ruka escrito em 2015 no seu blog, em que ele diz que o Git Flow é considerado prejudicial. A principal condição para se usar o One Flow é que cada nova versão de produção seja baseada na versão anterior. A principal diferença entre o One Flow e o Git Flow é que esse modelo não contém a branch develop.


Algumas vantagens:


  • o histórico do Git será mais limpo, menos confuso e mais legível;

  • é flexível de acordo com a necessidade do time;

  • é ideal quando se precisa de uma única versão em produção.

Algumas desvantagens:


  • não é aconselhável para entregas contínuas e integração contínua;

  • não é recomendado quando se precisa de mais de uma versão em produção.


Chegamos ao fim de mais um artigo e com isso esperamos que você tenha entendido o básico sobre o Git Flow. Com os temas abordados e os exemplos práticos, fica mais fácil de entender os conceitos dessa estrutura. Como comentamos, o Git Flow não é uma bala de prata para resolver os problemas relacionados ao Git, e sim um fluxo de trabalho que, em alguns casos, facilita o desenvolvimento de novas funcionalidades e versionamento de projeto.


Nem sempre você precisa utilizar todas as regras e condições determinadas pela estrutura. Você pode utilizar as boas partes do fluxo, tais como o desenvolvimento em paralelo, a solução de bugs em produção e ainda mais a solução de bugs em develop. Sendo assim, não fique travado com as condições que o Git Flow impõe, pense fora da caixa e adapte para o seu tipo de trabalho.

__________________________________________________________________________________


Notas e Relacionados


> Inicialmente o nosso propósito com o Blog é efetuar postagens diversas, porém teremos a área separada para as postagens relacionadas ao Constructor SO, que é o nosso Portfólio de Projetos, Agiles e Scrum, em que cada membro do Constructor SO possui a sua área para os seus desenvolvimentos. Dessa forma, cada atualização da área do Constructor SO é seguida de uma postagem no blog do profissional, informando os nossos leitores e criando assim um panorama extensivo de tal trabalho lançado ou versionado;


> A priori em relação aos desenvolvimentos da Space_One Labs, a nossa ideia é lançar e trabalhar de forma aleatória vários projetos da área específica relacionada, não nos tornando assim limitados por apps ou softwares específicos;


> Todos os casos aqui descritos e desenvolvidos, para este blog, no qual me pertence, que seja da categoria "BI Case", são casos de empresas fictícias, criadas e inventadas, para contextualizar e deixar o trabalho mais vivo e realista possível.




__________________________________________________________________________________


Daniel Sanches


Engenheiro de Produção, Universo - Universidade Salgado de Oliveira, especializado em Analytics e Data, Business e Tecnologia.


SO Labs Developer Member of Research, Business Intelligence Analyst, Data Analyst and Business Analyst, Data Engineer, Blogger DS Space_One Labs | Space Members


Membro SO Labs Desenvolvedor de Pesquisas, Business Intelligence, Data Engineer, Data Analyst e Negócios

Comments


bottom of page