Estrategias de branching para equipos de datos: GitFlow vs trunk-based

João Barros 23 de January de 2026 1 min de lectura

La estrategia de branching define cómo fluyen los cambios desde el desarrollo hasta producción. Para los equipos de datos, la elección entre GitFlow y trunk-based development tiene implicaciones directas en la frecuencia de deploy y en la complejidad de merge.

GitFlow — estructura y flujo

Branches permanentes:
  main    → código en producción (protegida, merge vía PR)
  develop → integración de features en curso

Branches temporales:
  feature/ingest-clientes-v2  → nueva funcionalidad
  hotfix/corregir-watermark   → corrección urgente en prod
  release/2024-Q2             → preparación de release

Flujo:
  feature/* → develop → (pruebas) → release/* → main
  hotfix/*  → main + develop

Trunk-Based Development

Un único branch principal: main
Feature branches muy cortos (< 2 días)
Deploy automático tras un PR mergeado

Flujo:
  main ← feature/fix (PR con 1-2 commits, vida corta)
  Cada merge → CI/CD automático → deploy a staging → (aprobación) → prod

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

Comparación para equipos de datos

GitFlow — mejor cuando:
  ✓ Releases programadas (mensual, trimestral)
  ✓ Múltiples analistas trabajando en paralelo
  ✓ Informes Power BI con un ciclo de validación largo
  ✓ Equipo menos experimentado en git

Trunk-based — mejor cuando:
  ✓ Deploy continuo de pipelines de datos
  ✓ Notebooks testeables automáticamente
  ✓ Equipo experimentado con CI/CD
  ✓ Feature flags para rollout gradual

Recomendación práctica para datos

Para la mayoría de los equipos de datos:
  - GitFlow simplificado: main + develop + feature/*
  - PR obligatorio para develop y main
  - Pipeline CI en cada PR (lint + pruebas)
  - Deploy automático a dev/test, aprobación manual para prod
  - Proteger main y develop: requerir 1 reviewer + CI verde

Conclusión

El GitFlow simplificado (sin release/* separados) es el equilibrio correcto para la mayoría de los equipos de datos. Aporta suficiente estructura para coordinar a múltiples contribuidores sin la sobrecarga del trunk-based puro, que requiere feature flags y pipelines de deploy muy maduros.