No desenvolvimento de software moderno, o uso de sistemas de controle de versão é essencial, e o Git se tornou a ferramenta padrão. No entanto, ter apenas o Git não é suficiente; é preciso definir um fluxo de trabalho que organize como as branches são criadas, mescladas e gerenciadas. Esta aula apresenta os principais fluxos de trabalho com Git, detalhando suas estruturas, práticas recomendadas e contextos de uso.

Entender esses fluxos é fundamental para equipes de DevOps, pois impacta diretamente a integração contínua, entrega contínua e a estabilidade do código em produção. Vamos explorar GitFlow, Trunk-based development e Feature branches, comparando-os para que você possa escolher o mais adequado para seu projeto.

GitFlow

GitFlow é um modelo de branching criado por Vincent Driessen em 2010. Ele define um conjunto rigoroso de branches para gerenciar o desenvolvimento, releases e correções de emergência. As branches principais são main (ou master) e develop. A partir de develop, criam-se branches de funcionalidades (feature/), branches de release (release/) e branches de hotfix (hotfix/).

Esse fluxo é ideal para projetos com ciclos de release planejados, onde há necessidade de suporte a múltiplas versões em paralelo. No entanto, sua complexidade pode ser excessiva para equipes que praticam entrega contínua, pois as branches de release podem atrasar a integração.

Exemplo de comandos para iniciar uma nova funcionalidade:

git checkout develop
git checkout -b feature/nova-funcionalidade
# ... desenvolvimento ...
git checkout develop
git merge --no-ff feature/nova-funcionalidade
git branch -d feature/nova-funcionalidade

Trunk-based development

Trunk-based development (TBD) é um fluxo onde os desenvolvedores trabalham em branches de curta duração (ou diretamente no trunk, geralmente main) e integram suas alterações várias vezes ao dia. O objetivo é evitar branches longas e conflitos de merge, promovendo integração contínua.

Nesse modelo, as branches de funcionalidade existem por no máximo algumas horas. Para releases, utiliza-se tags ou branches de release efêmeras. TBD é amplamente adotado em ambientes de DevOps e CI/CD, pois reduz o tempo de feedback e acelera a entrega.

Exemplo de prática comum no TBD:

git checkout main
git pull
git checkout -b minha-feature
# ... desenvolvimento com commits frequentes ...
git rebase main # para manter atualizado
git checkout main
git merge --squash minha-feature
git branch -D minha-feature

Feature branches

Feature branches é uma abordagem mais simples onde cada nova funcionalidade é desenvolvida em uma branch dedicada, criada a partir de main (ou develop). Após a conclusão, a branch é mesclada de volta. Diferente do GitFlow, não há branches de release ou hotfix predefinidos; a equipe decide como gerenciar releases.

Esse fluxo é flexível e pode ser combinado com outras práticas. É comum em equipes pequenas ou projetos que ainda não adotaram um modelo mais estruturado. No entanto, sem disciplina, pode levar a branches longas e difíceis de integrar.

Exemplo:

git checkout main
git pull
git checkout -b feature/autenticacao
# ... desenvolvimento ...
git push origin feature/autenticacao
# ... revisão de código ...
git checkout main
git merge feature/autenticacao
git push origin main

Comparação

A escolha entre GitFlow, Trunk-based development e Feature branches depende do contexto da equipe, tamanho do projeto e frequência de releases. GitFlow oferece controle e suporte a múltiplas versões, mas é mais complexo. TBD simplifica a integração contínua e é recomendado para equipes maduras em DevOps. Feature branches são um meio-termo, mas exigem disciplina para evitar branches longas.

Na prática, muitas equipes adotam variações: por exemplo, usam TBD com branches de curta duração e releases via tags, ou GitFlow simplificado sem branches de release. O importante é alinhar o fluxo com as práticas de CI/CD e o ciclo de vida do software.

Boas práticas

  • Manter branches de curta duração (horas ou dias) para reduzir conflitos.
  • Integrar frequentemente com a branch principal.
  • Usar pull requests para revisão de código.
  • Automatizar testes e builds para cada push.
  • Documentar o fluxo escolhido e treinar a equipe.

Referências

Exercícios

  1. Explique a diferença fundamental entre GitFlow e Trunk-based development em relação à frequência de integração.

    2. ✓ Resposta: No GitFlow, as branches de funcionalidade podem durar dias ou semanas, e a integração com a branch develop ocorre apenas quando a funcionalidade está completa. Já no Trunk-based development, as branches são de curta duração (horas) e a integração com o trunk é feita várias vezes ao dia, promovendo integração contínua.
  2. Qual fluxo de trabalho é mais adequado para um projeto que precisa manter versões antigas em produção enquanto desenvolve novas funcionalidades? Justifique.

    3. ✓ Resposta: O GitFlow é mais adequado, pois possui branches de release e hotfix que permitem corrigir e manter versões antigas (ex.: v1.0) enquanto o desenvolvimento da v2.0 ocorre em paralelo na branch develop. O Trunk-based development geralmente não oferece suporte a múltiplas versões simultâneas.
  3. No Trunk-based development, como são gerenciadas as releases?

    4. ✓ Resposta: Releases no TBD são geralmente feitas a partir do trunk (main) usando tags. Pode-se criar uma branch de release temporária para estabilização, mas ela é de curta duração e mesclada de volta rapidamente. O foco é que o trunk esteja sempre em estado pronto para release.
  4. Cite uma vantagem e uma desvantagem do uso de Feature branches em comparação com GitFlow.

    5. ✓ Resposta: Vantagem: Simplicidade - menos branches e regras, fácil de entender. Desvantagem: Falta de estrutura para releases e hotfixes, o que pode levar a problemas de coordenação em projetos maiores.
  5. Qual comando Git é usado no GitFlow para mesclar uma branch de funcionalidade de volta para develop, preservando o histórico de merges?

    6. ✓ Resposta: O comando é git merge --no-ff. A opção --no-ff (no fast-forward) cria um commit de merge mesmo quando o merge poderia ser fast-forward, preservando a informação de que a branch existiu.