Cuando varios desarrolladores tocan el mismo repositorio, el código termina en caos: merges rotos, bugs en producción y reversiones imposibles. Una estrategia de ramificación clara soluciona ese problema y aquí verás cómo aplicar Gitflow y Trunk Based Development para mantener el control en cada release.

¿Qué es Gitflow y cuándo conviene usarlo?

Gitflow es un modelo de ramificación pensado para equipos grandes que necesitan trazabilidad detallada de cada cambio. La idea central es simple: cada issue tiene su propia rama y todas parten de una rama base llamada Develop.

¿Qué es Gitflow? Es una estrategia de ramificación donde creas una rama por cada issue a partir de Develop, y luego la integras vía pull request. Se usa en equipos con muchos desarrolladores que requieren control granular.

Este flujo es el que usan la mayoría de empresas con plantillas grandes de ingeniería, porque permite revisar cada cambio de forma aislada antes de mezclarlo con el resto.

¿En qué se diferencia de Trunk Based Development?

La diferencia es directa y afecta cómo agrupas el trabajo [00:30]:

• En Gitflow creas una rama por cada issue individual.
• En Trunk Based Development agrupas una lista de issues y creas una sola rama para esa lista.
• Gitflow prioriza control; Trunk Based prioriza velocidad de integración.

La elección depende del tamaño del equipo y de qué tan rápido necesitas mover cambios a producción.

¿Cómo conectar Jira y GitHub para automatizar ramas?

Automatizar la creación de ramas evita errores de nombres y mantiene la trazabilidad entre tarea y código. La integración entre Jira y GitHub se hace en pocos pasos [01:00]:

1. Entra a la configuración de Jira y abre la sección de aplicaciones.
2. Busca GitHub for Jira, agrégala y confirma con adicionar.
3. Ve a GitHub, entra a settings y aplicaciones, y acepta el permiso solicitado por Jira.
4. Vuelve al proyecto en Jira para crear ramas directamente desde cada issue.

Una vez sincronizadas las herramientas, puedes seleccionar el proyecto, definir que la rama parta de Develop y dejar el nombre por defecto que sugiere Jira. Ese nombre incluye el ID del issue, lo que mantiene un control claro entre tarea y código.

¿Por qué dejar el nombre por defecto que sugiere Jira? Porque incluye el identificador del issue, lo que conecta automáticamente la rama con su tarea y facilita el seguimiento en ambas herramientas.

¿Cómo se ve el flujo completo en GitHub?

Después de trabajar en la rama y resolver el issue, creas un pull request. Cuando se acepta, la rama se integra a Develop y posteriormente se mergea con main [01:50].

En la vista de GitHub puedes observar cómo la rama se divide cada vez que se aborda un issue nuevo. Al final del flujo aparece un tag, que marca el punto exacto en el que la aplicación fue lanzada.

¿Qué significa el tag de versión en el repositorio?

El tag funciona como una etiqueta que agrupa todo lo que entró en una versión específica. Por ejemplo, todos los issues que estén debajo del tag 1.01 son los que viajan en esa versión publicada.

Esto te da dos beneficios concretos:

• Sabes exactamente qué cambios contiene cada release.
• Puedes revertir o auditar una versión sin perderte entre commits sueltos.

Una estrategia de ramas clara es solo la mitad del trabajo. La otra mitad es decidir quién recibe la actualización y cuándo, algo que se resuelve con canales de distribución y herramientas como Firebase. ¿Tú qué modelo usas en tu equipo, Gitflow o Trunk Based? Cuéntame en los comentarios.