Elegir una Estrategia de Ramificación

El desarrollo basado en trunk lleva el principio de "las ramas deben ser de corta duración" a su conclusión lógica: las ramas viven horas, no días. Los ingenieros envían cambios pequeños e incrementales a main varias veces al día, usando feature flags para ocultar el trabajo incompleto de los usuarios.

Las ventajas son reales. Los problemas de integración surgen inmediatamente porque las ramas nunca se alejan mucho de main. Las ejecuciones de CI son rápidas porque el diff es pequeño. No hay "día de merge" porque el merge es continuo. Los equipos que practican desarrollo basado en trunk reportan frecuencias de despliegue de 4 a 8 veces más altas que los equipos que usan ramas de larga duración.

Los requisitos también son reales. El desarrollo basado en trunk exige un CI excelente (las pruebas deben ser rápidas y confiables), infraestructura robusta de feature flags (necesitas enviar código incompleto de forma segura) y alta confianza entre ingenieros (sin revisión obligatoria significa que el autor asume toda la responsabilidad). Para un equipo de 4 personas con CI sólido y una base de código compartida, suele ser la forma más rápida de trabajar. Para un equipo de 30 personas con cobertura de pruebas irregular, es una receta para una rama main rota.

Esto es GitHub Flow llevado un paso más allá — menos ramas, duraciones más cortas, más dependencia en flags que en aislamiento.

GitHub Flow es el predeterminado correcto para la mayoría de los equipos, y vale la pena entender por qué. Todo el modelo cabe en tres reglas: main siempre es desplegable, cada cambio ocurre en una rama de corta duración, y las ramas se fusionan a main mediante PRs revisados. Eso es todo.

No hay rama develop, no hay rama release, no hay rama hotfix. Una rama por cambio, un PR por rama, un merge a main. Cuando main recibe un nuevo merge, puedes desplegarlo — manualmente, automáticamente o según un calendario. La simplicidad es la característica.

GitHub Flow funciona porque coincide con cómo la mayoría de los equipos de producto realmente envían: continuamente, en incrementos pequeños, sin la sobrecarga de coordinar trenes de lanzamiento. Una rama de feature vive uno o dos días, se revisa, se fusiona y se envía. Si rompe algo, reviertes y arreglas. El ciclo de retroalimentación es ajustado.

Donde GitHub Flow tiene dificultades es cuando necesitas mantener múltiples versiones de producción simultáneamente (envías v2.3 pero necesitas parchear v2.1 para un cliente), o cuando tu proceso de despliegue es lento y costoso (haciendo que "simplemente revertir" sea poco realista). Esos escenarios necesitan un modelo de ramificación más estructurado — pero son la excepción, no la regla.

GitFlow fue diseñado para un mundo donde el software se enviaba en CDs — lanzamientos versionados, ciclos largos de QA, múltiples versiones soportadas en el campo. Si ese es tu mundo (aplicaciones de escritorio, sistemas embebidos, software empresarial con soporte de versión contractual), la estructura de GitFlow justifica su complejidad.

El modelo agrega varias ramas de larga duración: develop (integración), release/* (estabilización), hotfix/* (parches de emergencia a producción) y main (estado de producción). Las features se ramifican desde develop, los releases se bifurcan desde develop cuando una versión está "completa en features", y los hotfixes se ramifican desde main directamente.

Para equipos que despliegan una aplicación web — que es la mayoría de los equipos leyendo este curso — GitFlow es casi con certeza excesivo. La rama develop agrega una capa de indirección entre tu trabajo y producción sin un beneficio proporcional. Las ramas de release solo tienen sentido si tienes una puerta formal de QA entre "código completo" y "enviado". Las ramas de hotfix son innecesarias cuando desplegar una corrección toma minutos, no semanas.

GitFlow no es malo. Está diseñado para un contexto específico. Si no tienes ese contexto (múltiples versiones soportadas, despliegues lentos, puertas formales de lanzamiento), estás pagando el impuesto de complejidad sin el beneficio. Comienza con GitHub Flow. Siempre puedes agregar estructura más adelante si la situación lo exige — pero rara vez necesitarás hacerlo.