O Git oferece branches, mas não diz como usá-las. Em uma equipe pequena sem convenção, rapidamente surgem dúvidas: onde fica o código que vai para produção? Como se trabalha em duas funcionalidades ao mesmo tempo? O que acontece quando um bug crítico precisa ser corrigido enquanto uma nova versão ainda está em desenvolvimento?
O Git Flow é um modelo de organização de branches que responde a essas perguntas. Foi proposto por Vincent Driessen em 2010 e se tornou um dos padrões mais adotados pela indústria. Não é o único modelo — existem alternativas como GitHub Flow e Trunk-Based Development — mas o Git Flow é o mais completo para entender os princípios antes de avaliar as alternativas.
As Cinco Branches do Git Flow
O modelo define dois tipos de branches: as permanentes, que existem durante toda a vida do projeto, e as temporárias, que nascem para uma tarefa e são removidas após o merge.
Branches permanentes:
main— contém o código que está em produção. Cada commit nessa branch representa uma versão lançada.develop— o ponto de integração contínua. Todas as funcionalidades concluídas chegam aqui antes de ir para produção.
Branches temporárias:
feature/*— para desenvolver novas funcionalidadesrelease/*— para preparar uma nova versão para produçãohotfix/*— para corrigir bugs críticos diretamente em produção
Instalando o Git Flow
A maioria das distribuições Linux oferece o git-flow como pacote:
sudo apt install git-flow # Debian/Ubuntu
Inicializando em um repositório existente:
git flow init
O comando faz algumas perguntas sobre os nomes das branches — aceitar os padrões é a escolha correta na maioria dos casos.
Fluxo de uma Nova Funcionalidade
# Inicia uma feature branch a partir da develop
git flow feature start configurar-monitoramento
# O Git cria e já muda para a branch feature/configurar-monitoramento
# Trabalha-se normalmente com commits
echo "# Prometheus Config" > prometheus.yml
git add prometheus.yml
git commit -m "feat: adiciona configuração base do Prometheus"
# Quando a funcionalidade está pronta, finaliza-se
git flow feature finish configurar-monitoramento
O feature finish faz o merge de volta para develop, remove a branch de feature e volta para develop. Tudo em um único comando.
Preparando uma Release
Quando a develop tem um conjunto de funcionalidades prontas para ir a produção, cria-se uma branch de release:
# Inicia a release com o número de versão
git flow release start 1.2.0
Nessa branch, fazem-se apenas ajustes finais: atualização de número de versão, correções menores, atualização de changelog. Nenhuma funcionalidade nova entra aqui.
# Atualiza o arquivo de versão
echo "1.2.0" > VERSION
git add VERSION
git commit -m "chore: bump version to 1.2.0"
# Finaliza a release
git flow release finish 1.2.0
O release finish faz três coisas automaticamente:
- Merge na
main(marcando o código de produção) - Cria uma tag
1.2.0namain - Merge de volta na
develop(para que as correções feitas na release não se percam)
Corrigindo Bugs em Produção com Hotfix
Imagine que um bug crítico foi descoberto em produção. Não é possível esperar o ciclo normal de desenvolvimento — a correção precisa ir direto para a main:
# Inicia o hotfix a partir da main
git flow hotfix start 1.2.1
# Corrige o bug
git add .
git commit -m "fix: corrige falha de autenticação em requests concorrentes"
# Finaliza
git flow hotfix finish 1.2.1
O hotfix finish faz merge tanto na main quanto na develop, garantindo que a correção também esteja presente no código em desenvolvimento.
Git Flow sem o Plugin
É perfeitamente possível seguir o modelo Git Flow sem o plugin, usando apenas os comandos nativos do Git. O plugin é um atalho — entender o que acontece por baixo é mais importante:
# Equivalente ao git flow feature start minha-feature
git checkout develop
git checkout -b feature/minha-feature
# Equivalente ao git flow feature finish minha-feature
git checkout develop
git merge --no-ff feature/minha-feature
git branch -d feature/minha-feature
O flag --no-ff (no fast-forward) força a criação de um merge commit mesmo quando o fast-forward seria possível. Isso preserva no histórico a evidência de que aquele conjunto de commits veio de uma feature branch — informação valiosa ao auditar o histórico.
Quando Usar Git Flow — e Quando Não Usar
O Git Flow brilha em projetos com ciclos de release definidos — aplicações com versões numeradas, bibliotecas, produtos com janelas de lançamento planejadas.
Ele é excessivo para equipes que fazem deploy contínuo — onde cada commit na branch principal pode ir a produção a qualquer momento. Nesses casos, modelos mais simples como o GitHub Flow (apenas main e feature branches) ou Trunk-Based Development (todos trabalham diretamente na main com feature flags) são mais adequados.
A escolha do modelo depende do ritmo de entregas da equipe e da maturidade do pipeline de CI/CD — assunto que será aprofundado no Módulo 4.
O Que Vem a Seguir
No próximo artigo será abordado o GitHub Actions — a ferramenta que transforma eventos no repositório em automações: testes que rodam a cada push, deploys que acontecem a cada merge na main, notificações automáticas. É onde Git e DevOps se conectam de forma concreta pela primeira vez.
Referências para Aprofundamento
Artigo original e evolução
- A Successful Git Branching Model — Vincent Driessen — O artigo original de 2010 que introduziu o Git Flow. O próprio autor adicionou uma nota em 2020 discutindo quando o modelo é e não é adequado.
- GitHub Flow — GitHub Docs — A alternativa mais simples ao Git Flow, usada pelo próprio GitHub. Boa leitura para entender os trade-offs entre os modelos.
Leitura complementar
- Trunk Based Development — Site dedicado ao modelo de desenvolvimento baseado em trunk, com argumentos técnicos sobre escalabilidade e integração contínua.
- Pro Git — Capítulo 3: Branching — Capítulo em português do Pro Git cobrindo o modelo interno de branches e merge do Git.
Prática
- Learn Git Branching — Os níveis avançados do simulador cobrem merges complexos e rebase, que complementam o entendimento do Git Flow.