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.
#BlogdeMembros #BlogSOLabs / #git #GitHub #Gitflow #Versionamento #Code #Data #DataEngineer #DataArchitect
__________________________________________________________________________________
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