4 min lectura • Guide 817 of 877
Trunk-Based Development
Integra continuamente. GitScrum soporta workflows de trunk-based development donde equipos integran frecuentemente al branch principal para feedback y entrega más rápida.
Entendiendo Trunk-Based Development
TRUNK-BASED DEVELOPMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EL CONCEPTO: │
│ ──────────── │
│ Todos integran a main/trunk frecuentemente │
│ Branches de corta vida (horas, no semanas) │
│ Integración continua a codebase compartido │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TRUNK-BASED: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ main ─●──●──●──●──●──●──●──●──●──●──●──●──→ ││
│ │ ╲╱ ╲╱ ╲╱ ╲╱ ╲╱ ││
│ │ ─● ─● ─● ─● ─● ││
│ │ (branches cortos - horas/día) ││
│ │ ││
│ │ • Merges pequeños y frecuentes ││
│ │ • Conflictos son pequeños y fáciles ││
│ │ • Siempre shippable ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VS GITFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ main ─●────────────────────────●────→ ││
│ │ develop ─●──●──●──●──●──●──●──●──●●───→ ││
│ │ ╲ ╱ ││
│ │ feature ──●────●────●────●────●─ ││
│ │ (semanas/meses) ││
│ │ ││
│ │ • Merges grandes al final ││
│ │ • Dolor de integración ││
│ │ • "Merge hell" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIFERENCIA CLAVE: │
│ Trunk-based = Integrar seguido, batches pequeños │
│ GitFlow = Integrar al final, batches grandes │
└─────────────────────────────────────────────────────────────┘
Cómo Funciona
WORKFLOW TRUNK-BASED:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FLOW DIARIO: │
│ ──────────── │
│ │
│ 1. PULL LATEST │
│ git pull origin main │
│ Empieza con código más reciente │
│ │
│ 2. CREAR BRANCH CORTO │
│ git checkout -b add-user-validation │
│ Nombra por tarea específica │
│ │
│ 3. HACER CAMBIOS PEQUEÑOS │
│ Commits pequeños y enfocados │
│ Idealmente completable en un día │
│ │
│ 4. PUSH Y PR │
│ git push origin add-user-validation │
│ Abrir PR para review │
│ │
│ 5. MERGE RÁPIDO │
│ Review y merge el mismo día │
│ Eliminar branch después │
│ │
│ 6. REPETIR │
│ Múltiples ciclos por día es bueno │
│ │
└─────────────────────────────────────────────────────────────┘
Feature Flags
SEPARANDO DEPLOYMENT DE RELEASE
═══════════════════════════════
EL PROBLEMA:
┌─────────────────────────────────────────────────────────────┐
│ ¿Cómo mergeas código incompleto a main? │
│ ¿No verán los usuarios features a medias? │
└─────────────────────────────────────────────────────────────┘
LA SOLUCIÓN: FEATURE FLAGS
┌─────────────────────────────────────────────────────────────┐
│ │
│ if (featureFlags.isEnabled('new-checkout')) { │
│ // Nuevo código de checkout │
│ showNewCheckout(); │
│ } else { │
│ // Código existente │
│ showLegacyCheckout(); │
│ } │
│ │
│ BENEFICIOS: │
│ • Código en main, oculto de usuarios │
│ • Habilita gradualmente (canary, % rollout) │
│ • Rollback instantáneo si hay problemas │
│ • Developers pueden testear en producción │
│ │
└─────────────────────────────────────────────────────────────┘