Git Flow na prática: feature, release e hotfix

Git Flow é um modelo de branches proposto por Vincent Driessen em 2010. A ideia é simples: cada branch tem um papel fixo. Isso deixa claro o que está em produção, o que vai entrar na próxima versão e o que é correção urgente.

Neste guia você vai ver para que serve cada branch, os comandos de cada fluxo, como nomear branches e versões, os erros mais comuns e em que tipo de projeto o modelo realmente ajuda.

Os branches do Git Flow

• main: o que está em produção. Cada merge aqui vira uma versão, marcada com uma tag.
• develop: onde as features se encontram antes da próxima versão.
• feature/*: saem da develop e voltam para a develop quando ficam prontas.
• release/*: saem da develop para preparar uma versão. Voltam para a main e para a develop.
• hotfix/*: saem da main para corrigir produção. Voltam para a main e para a develop.

A main e a develop vivem para sempre. As outras são temporárias: nascem, cumprem o papel e são apagadas.

O fluxo de uma feature

Uma feature nasce da develop, recebe os commits do trabalho e volta para a develop com um merge:

git switch develop
git pull
git switch -c feature/login-sso
# commits da feature
git switch develop
git merge --no-ff feature/login-sso
git branch -d feature/login-sso
git push origin develop

O --no-ff cria um commit de merge mesmo quando o Git poderia só avançar o ponteiro. Assim o histórico mostra onde a feature começou e onde terminou, o que ajuda muito na hora de revisar ou reverter a feature inteira.

Em times que usam pull requests, o merge na develop costuma acontecer pelo GitHub, GitLab ou Azure DevOps, depois da revisão. A lógica é a mesma.

Fechando uma release

Quando a develop tem o que deve sair na próxima versão, abra um branch de release. A partir daí o escopo está congelado: entram só correções, ajuste de número de versão e changelog.

git switch -c release/1.4.0 develop
# ajustes finais, versão e changelog
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Versão 1.4.0"
git switch develop
git merge --no-ff release/1.4.0
git branch -d release/1.4.0
git push origin main develop --tags

Enquanto a release está aberta, o time pode continuar abrindo features na develop. Elas só entram na versão seguinte.

Corrigindo produção com um hotfix

O hotfix segue a mesma lógica, mas parte da main, porque precisa corrigir exatamente o que está em produção:

git switch -c hotfix/1.4.1 main
# correção
git switch main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Versão 1.4.1"
git switch develop
git merge --no-ff hotfix/1.4.1
git branch -d hotfix/1.4.1

Levar a correção para a develop é o passo mais esquecido. É ele que impede o bug de voltar na versão seguinte. Se houver uma release aberta, leve o hotfix para ela em vez da develop.

Nomes de branch e versões

• Use prefixos fixos: feature/, release/ e hotfix/. Ferramentas e pipelines dependem deles.
• Na feature, descreva o assunto ou use o número da tarefa: feature/login-sso ou feature/1234-login-sso.
• Na release e no hotfix, use o número da versão: release/1.4.0 e hotfix/1.4.1.
• Siga o versionamento semântico: o terceiro número sobe em correções, o segundo em novidades compatíveis e o primeiro em mudanças que quebram compatibilidade.

Git Flow, GitHub Flow ou trunk-based?

• Git Flow: bom para produtos com versões numeradas, apps desktop e mobile, bibliotecas e sistemas que mantêm mais de uma versão em paralelo.
• GitHub Flow: só a main e branches curtos com pull request. Bom para aplicações web publicadas várias vezes por semana.
• Trunk-based: todo mundo integra na main várias vezes por dia, com feature flags para esconder o que não está pronto. Bom para times maduros com testes automatizados fortes.

Não existe modelo certo para todo mundo. Se o seu time publica em produção várias vezes por dia, o Git Flow vai parecer burocrático. Se você entrega versões para clientes instalarem, ele organiza muito o trabalho.

Os erros mais comuns

• Esquecer de levar o hotfix de volta para a develop.
• Deixar a release aberta por semanas, até ela virar uma segunda develop.
• Features que vivem muito tempo sem receber a develop e acumulam conflitos.
• Fazer commits direto na main ou na develop, sem passar por um branch.
• Esquecer de criar a tag, o que deixa a versão em produção sem referência no histórico.

Git Flow no GitMuninn

No plano Pro, o GitMuninn inicia e conclui features, releases e hotfixes com os prefixos que o seu repositório já usa, sem decorar a sequência de comandos. E como cada branch tem uma cor no grafo, fica fácil ver se um hotfix já voltou para a develop ou se uma release ainda está aberta.