Fluxo de trabalho Gitflow

Visão geral

O Gitflow é um modelo estruturado de ramificação, popularizado por Vincent Driessen em 2010, projetado para projetos com lançamentos programados e versionados. Em vez de um único branch de integração, ele utiliza dois branches de longa duração mais três tipos de branches de suporte, cada um com um propósito definido. A estrutura torna o gerenciamento de releases explícito ao custo de mais cerimônia.

Os dois branches de longa duração

Esses dois branches existem durante toda a vida do projeto — você nunca os exclui.

• main contém o código pronto para produção. Cada commit em main corresponde a uma versão lançada e geralmente recebe uma tag (por exemplo, v1.4.0). Se você quiser saber exatamente o que está rodando em produção, faça checkout do main.
• develop é o branch de integração onde as funcionalidades concluídas se acumulam entre os lançamentos. Ele sempre contém as últimas alterações entregues destinadas ao próximo release, mas essas alterações não são necessariamente estáveis ainda.

Como ambos os branches são permanentes, a relação entre eles nunca é redefinida: develop está sempre "à frente" de main por tudo que ainda não foi lançado.

Os três branches de suporte

Os branches de suporte são de curta duração. Cada um é criado para um propósito, mesclado quando esse propósito é cumprido e depois excluído. As convenções de nomenclatura (feature/, release/, hotfix/) mantêm seu papel óbvio na saída do git branch.

Branches de feature

Os branches de feature derivam de develop e são mesclados de volta em develop. Eles contêm o trabalho para funcionalidades futuras e nunca interagem diretamente com main — uma única feature nunca é lançada por conta própria; ela é entregue como parte do próximo release versionado.

git switch develop
git switch -c feature/search   # create + check out feature/search
# ...work and commit...
git switch develop
git merge feature/search       # fold the feature into develop
git branch -d feature/search   # delete it once merged

Um git switch -c <name> cria o branch a partir do branch atual e faz checkout dele em uma única etapa — é o equivalente moderno de git checkout -b. Consulte Git switch para o comando completo. Manter os branches de feature de curta duração limita o quanto eles se afastam de develop, o que mantém os conflitos de merge pequenos.

Branches de release

Os branches de release derivam de develop quando ele está com as features completas para um lançamento. Eles existem apenas para polimento final — atualizações de versão, notas de release e correções de bugs de última hora — enquanto develop permanece aberto para as features do próximo ciclo.

Quando o release está pronto, o branch é mesclado nos dois lugares:

• em main, onde recebe uma tag com o número de versão; e
• de volta em develop, para que quaisquer correções de estabilização feitas no branch de release não sejam perdidas.

git switch -c release/1.4.0 develop
# ...bump version, fix last bugs, write release notes...
git switch main
git merge --no-ff release/1.4.0      # record an explicit merge commit
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0      # carry fixes back into develop
git branch -d release/1.4.0

--no-ff (no fast-forward) força o Git a criar um commit de merge mesmo quando um fast-forward seria possível, de modo que o release seja preservado como um ponto único e visível no histórico, em vez de ser eliminado.

Branches de hotfix

Os branches de hotfix derivam de main para corrigir urgentemente um bug em produção — sem esperar que o trabalho atual em develop esteja pronto para release. Assim como os branches de release, eles são mesclados nos dois lugares: em main (com uma tag de versão de patch incrementada) e em develop, para que a correção também esteja presente em releases futuros.

git switch -c hotfix/1.4.1 main
# ...fix the bug and commit...
git switch main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop
git merge --no-ff hotfix/1.4.1       # don't reintroduce the bug later
git branch -d hotfix/1.4.1

Esquecer o segundo merge — de volta em develop — é o erro clássico do Gitflow: o bug reaparece no próximo release porque a correção só foi aplicada em main.

Quando usar o Gitflow

O Gitflow brilha quando você entrega releases distintos e versionados — aplicativos desktop, bibliotecas, aplicativos móveis sujeitos à revisão da loja de aplicativos, ou qualquer coisa com números de versão mantidos e correções emergenciais ocasionais. Os branches explícitos de release e hotfix oferecem um lugar claro para estabilizar e corrigir a produção sem perturbar o desenvolvimento em andamento. A necessidade de dar suporte a múltiplas versões lançadas simultaneamente é o sinal mais forte de que a estrutura do Gitflow valerá a pena.

Um ciclo de release completo em resumo

Juntando as peças, uma versão percorre os branches assim:

1. Os desenvolvedores criam branches feature/* a partir de develop, constroem e mesclam cada um de volta em develop.
2. Quando develop tem o suficiente para um release, um branch release/x.y.0 é criado para estabilização final.
3. O branch de release é mesclado em main, recebe a tag vx.y.0 e é mesclado de volta em develop.
4. Se a produção falhar, um hotfix/x.y.z deriva de main, recebe uma tag e é mesclado tanto em main quanto em develop.

main portanto avança apenas por meio de merges de release e hotfix, e cada commit nele é uma versão entregável e tagueada.

As compensações

Essa estrutura é também a fraqueza do Gitflow. Os muitos tipos de branches adicionam sobrecarga, e o branch develop de longa duração pode se afastar muito de main, tornando os merges dolorosos. Branches de longa duração incentivam integrações grandes e pouco frequentes — o oposto do que a entrega contínua deseja. Times que fazem deploy muitas vezes ao dia geralmente acham o Gitflow muito pesado e preferem a abordagem mais simples de branch de feature ou trunk-based, onde o trabalho é integrado continuamente em um único branch. Escolha o Gitflow quando a cadência de releases e o suporte a versões paralelas, e não a velocidade bruta de deploy, forem suas prioridades.

Compare-o com as alternativas antes de se comprometer: o fluxo de fork para contribuições de código aberto, e simples branches de feature para a maioria dos aplicativos web que fazem deploy a partir de uma única linha.

Prática