Usando Git Flow? Oops...
Sua equipe usa Git Flow? Então deixa eu te dar uma má notícia: provavelmente vocês tomaram uma decisão (bem) ruim.
Frequentemente, quando começamos uma consultoria de DevOps num cliente, uma das primeiras coisas que avaliamos é qual a estratégia de versionamento de código que as equipes estão usando.
E, para as que trabalham com Git, a resposta é quase invariavelmente a mesma:
“Git Flow”.
Dada a popularidade do Git Flow como fluxo de trabalho de equipes que usam o Git, era de se esperar que fosse a melhor escolha - um fluxo versátil e conveniente, que atende à demanda de equipes diferente com realidades diversas. Só que não é. Aliás, longe disso.
Para entender o porquê de o Git Flow provavelmente não ser a melhor escolha para sua equipe, é importante conhecer de onde ele veio, e principalmente seu contexto histórico.
Sobre o Git Flow
O Git Flow foi criado por Vincent Driessen em 2010, a partir do processo de desenvolvimento que ele construiu para gerenciar seus próprios projetos de software. À época, o Git ainda estava “engatinhando” e disputando o espaço com outros sistemas de controle de versão, como o Subversion e o Mercurial. O GitHub, por exemplo, havia sido lançado apenas dois anos antes.
Driessen escreveu um blog post descrevendo em detalhes sua abordagem, que desde então se tornou prática comum no desenvolvimento de software, especialmente para equipes em médias e grandes empresas.
Como funciona?
O Git Flow é baseado em duas branches principais, “master” e “develop”, além de outras branches temporárias para o desenvolvimento de novas funcionalidades, correções de bugs e outras tarefas. A branch “develop” é usada para a integração de código, enquanto a “master” é a branch estável, usada para lançamentos de produção.
Para muitas pessoas, o Git Flow é considerado um modelo de branching sofisticado, especialmente útil para projetos grandes e complexos com várias equipes trabalhando em diferentes recursos ao mesmo tempo. Ele se propõe a fornecer uma estrutura para controlar o fluxo de trabalho, rastrear o progresso do desenvolvimento e garantir que as mudanças sejam cuidadosamente gerenciadas e integradas ao código principal de uma maneira controlada e organizada.
Mas será que ele realmente funciona tão bem quanto as pessoas acreditam?
A controvérsia
Eu tenho minha própria opinião a respeito do Git Flow (que vou compartilhar em instantes com você), mas queria começar com uma citação do próprio Vincent Driessen, que diz em sua nota de reflexão:
This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.
O problema começa aqui, quando o autor comenta que o Git Flow se tornou uma espécie de “padrão” para muitas equipes, e que muitas pessoas o tratam como um dogma ou panaceia. Já viu isso acontecer em outros casos também?
Pois é, eu também.
Muitas pessoas começaram a tratar o Git Flow como o fluxo de trabalho “padrão” do Git, sem nem mesmo se perguntar porquê.
During those 10 years, Git itself has taken the world by a storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don’t have to support multiple versions of the software running in the wild.
Na minha opinião, este é o maior problema. Grande parte das equipes de desenvolvimento hoje em dia trabalha em aplicações LOB (line-of-business) e/ou aplicações Web. Nestes casos, o modelo de implantação e versionamento segue a ideia da Entrega Contínua, onde o software é implantado continuamente (sobrepondo a versão anterior), sem a necessidade de suporte a múltiplas versões simultâneas em produção. Neste cenário, o Git Flow não faz sentido - para quê manter várias branches de versões diferentes (releases, hotfixes etc.) se você só tem uma versão em produção?! Não faz o menor sentido. Cria um overhead desnecessário e, pior, pode gerar confusão e problemas de integração.
This is not the class of software that I had in mind when I wrote the blog post 10 years ago. 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 Git Flow não foi criado pensando nessas aplicações de versionamento único. Se sua equipe trabalha com Entrega Contínua, você deveria adotar um fluxo de trabalho mais simples (como GitHub Flow ou até mesmo Trunk-Based Development) ao invés de tentar forçar o Git Flow goela abaixo na sua equipe.
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on.
Aqui o autor lembra que há, sim, cenários onde o Git Flow faz sentido. Para quem trabalha com desenvolvimento de produtos que podem ter múltiplas versões simultâneas em produção - como bibliotecas, aplicações mobile e desktop, APIs e por aí vai - o controle oferecido pelo Git Flow pode realmente trazer valor para a equipe. Mas, novamente, é importante lembrar que o Git Flow não é a única opção.
To conclude, always remember that panaceas don’t exist. Consider your own context. Don’t be hating. Decide for yourself.
Em suma: evite ao máximo as “modinhas” e o culto à carga (“cargo cult”). Não é só porque alguém te disse que na empresa X ou Y eles usam o Git Flow que você deve adotá-lo também. Entenda seu contexto, suas necessidades, e escolha o fluxo de trabalho que melhor se encaixa na sua realidade.
Git Flow vs. GitHub Flow vs. Trunk-Based Development
Agora que já entendemos o contexto histórico do Git Flow, vamos compará-lo com outras duas abordagens de desenvolvimento de software: GitHub Flow e Trunk-Based Development.
GitHub Flow
O GitHub Flow é um fluxo de trabalho simples, baseado em uma única branch principal, chamada de “main” (ou “master”, dependendo da sua preferência). O foco do GitHub Flow está em usar feature branches para o desenvolvimento e teste de melhorias, integrando o código à branch principal apenas quando ele estiver em “qualidade de produção”.
Uma característica do GitHub Flow é o uso de pull requests para integrar as alterações na branch principal. Isso garante que o código seja revisado - manual e/ou automaticamente - antes de ser integrado.
O GitHub Flow é um modelo de trabalho ágil que enfatiza a colaboração e a comunicação entre os desenvolvedores, além de fornecer transparência e rastreabilidade do progresso do projeto. Ele é adequado para equipes de desenvolvimento que trabalham em um ritmo rápido e buscam uma maneira eficiente de gerenciar o código-fonte.
Vale lembrar que esse modelo foi concebido originalmente para ajudar a gerenciar o código-fonte de projetos open source hospedados no GitHub - daí a ênfase na agilidade, transparência e colaboração. Entretanto, ele serve muito bem também para projetos internos / de código fechado. Apesar do nome, ele nem mesmo exige que você use o GitHub como repositório remoto - você pode usar qualquer outro serviço ou ferramenta de sua escolha, como o Azure DevOps, GitLab, Bitbucket ou até mesmo o próprio servidor Git da sua empresa.
Trunk-Based Development
O Trunk-Based Development (“TBD”) é um fluxo de trabalho baseado em uma única branch principal, chamada de “trunk” (“tronco”). Todas as alterações são feitas diretamente nesta branch, e o código é implantado em produção assim que estiver pronto.
De acordo com a definição oficial no site, TBD é:
Um modelo de ramificação de código-fonte em que os desenvolvedores colaboram no código em uma única branch chamada ‘trunk’ (“main” ou “master” no Git) e resistem a qualquer pressão para criar outras branches de desenvolvimento de longa duração, empregando técnicas documentadas. Eles, portanto, evitam o “Merge Hell”, não quebram as builds e vivem felizes para sempre.
Os defensores de TBD argumentam que o uso de múltiplas branches é um desserviço às equipes, pois cria um overhead desnecessário e pode gerar confusão e problemas de integração. Ao utilizar uma única branch, reduz-se a sobrecarga tipicamente associada à gestão de várias branches. Essa sobrecarga não se deve apenas ao custo de criar e mesclar branches, mas também ao custo de acompanhar quais delas estão ativas e quais estão obsoletas. Quanto mais branches você tiver, maior o trabalho que você terá.
Isso significa, via de regra, que deve haver um processo de integração que precisa ser executado antes de enviar o código para a branch principal. Esse processo de integração, que pode ser manual ou automatizado, executa o build e os testes da aplicação. Ou seja, ele fazendo as vezes de um processo de CI, mas é executado na máquina da própria pessoa que está desenvolvendo (antes do commit/push), e não num servidor de build/CI.
Usar TBD, portanto, não significa abrir mão de qualidade e controle no processo de integração. Significa, na verdade, antecipar esses processos todos para que o código seja entregue já num estado “pronto”, sem a necessidade de passar por um processo de integração mais complexo.
Entretanto, nem sempre essa simplicidade toda é viável. Às vezes - em particular para equipes maiores - faz-se necessário ter algum nível de isolamento. O segredo, entretanto, é garantir que as branches sejam sempre de curta duração. Numa variação do TBD, o Scaled Trunk-Based Development, recomenda-se a criação de feature branches de curta duração (um a dois dias, no máximo), que são por sua vez integradas à branch principal (o “tronco”) por meio de pull requests e builds de integração.
Parece familiar? Pois é mesmo. O “Scaled Trunk-Based Development” é simplesmente o GitHub Flow com outro nome! Ok, isso não é exatamente verdade. A diferença é a “exigência” de que as branches sejam de curta duração. O GitHub Flow não faz essa exigência, mas é uma boa prática que deveria ser seguida de qualquer forma.
Minha preferência é…
Ok, sei que não vai dar para ficar “isentão” neste post, então vai lá: minha preferência é o GitHub Flow, mas com aquela recomendação do Scaled TBD de usar branches de curta duração.
Por quê? Porque ele é simples, fácil de entender e fácil de usar. Além disso, acredito que o uso de feature branches com pull requests pode trazer valor para equipes de todos os tamanhos.
Mas vale um alerta: O uso de GitHub Flow pode se tornar algo pesado e improdutivo se seus pull requests forem muito grandes e o processo de revisão for muito moroso e enfadonho. Isso acaba com o moral da equipe, então cuidado para não dar um tiro no pé! Pull requests são muito úteis, mas devem ser usados com inteligência.
Conclusão
O Git Flow tem, sim, seu valor - mas apenas para aquelas equipes que trabalham com software que precisa ter múltiplas versões em produção ao mesmo tempo - como APIs, apps e ERPs. Para a grande maioria dos cenários - equipes que trabalham com desenvolvimento de aplicações LOB ou aplicações Web, que sempre sobrescrevem a última versão em produção - o Git Flow não traz nenhum benefício, servindo apenas para criar um overhead completamente evitável.
E você, o que acha a respeito? Deixe sua opinião nos comentários!
Um abraço, e até a próxima!
Para saber mais
19/04/2023 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 10 mins.
