Estratégias de branching para equipas de dados: GitFlow vs trunk-based

A estratégia de branching define como as alterações fluem de desenvolvimento para produção. Para equipas de dados, a escolha entre GitFlow e trunk-based development tem implicações directas na frequência de deploy e na complexidade de merge.

GitFlow — estrutura e fluxo

Branches permanentes:
  main    → código em produção (protegida, merge via PR)
  develop → integração de features em curso

Branches temporárias:
  feature/ingest-clientes-v2  → nova funcionalidade
  hotfix/corrigir-watermark   → correcção urgente em prod
  release/2024-Q2             → preparação de release

Fluxo:
  feature/* → develop → (testes) → release/* → main
  hotfix/*  → main + develop

Trunk-Based Development

Um único branch principal: main
Feature branches muito curtos (< 2 dias)
Deploy automatico após PR mergeado

Fluxo:
  main ← feature/fix (PR com 1-2 commits, vida curta)
  Cada merge → CI/CD automático → deploy para staging → (aprovação) → prod

Para features grandes: feature flags
  if FEATURE_FLAG_NOVA_INGESTAO:
      run_new_pipeline()
  else:
      run_legacy_pipeline()

Comparação para equipas de dados

GitFlow — melhor quando:
  ✓ Releases agendadas (mensal, trimestral)
  ✓ Múltiplos analistas a trabalhar em paralelo
  ✓ Relatórios Power BI com ciclo de validação longo
  ✓ Equipa menos experiente em git

Trunk-based — melhor quando:
  ✓ Deploy contínuo de pipelines de dados
  ✓ Notebooks testáveis automaticamente
  ✓ Equipa experiente com CI/CD
  ✓ Feature flags para rollout gradual

Recomendação prática para dados

Para a maioria das equipas de dados:
  - GitFlow simplificado: main + develop + feature/*
  - PR obrigatório para develop e main
  - Pipeline CI em cada PR (lint + testes)
  - Deploy automático para dev/test, aprovação manual para prod
  - Proteger main e develop: requerer 1 reviewer + CI verde

Conclusão

GitFlow simplificado (sem release/* separados) é o equilíbrio certo para a maioria das equipas de dados. Fornece estrutura suficiente para coordenar múltiplos contribuidores sem a overhead de trunk-based puro, que requer feature flags e pipelines de deploy muito maduros.