Trunk Based Development vs Git Flow, cuál elegir

Entre los flujos de trabajo en Git más populares están Trunk Based Development y Git Flow. Uno se decanta por la forma estructural y el otro por la ligereza, pero no te quedes con ganas de saber cuál te conviene más aprender.

Tanto si eres desarrollador como alguien de infraestructuras, te viene bien conocer detalles y que te profesionalices en los dos o en al menos uno de ellos, ya que en un ambiente laboral donde los proyectos se trabajan de forma colaborativa, es importante mantener un modelo, una metodología de desarrollo y despliegue de nuevas características de dichos proyectos.

Es importante sentar algunas bases sobre este escrito, puesto que no está meramente dirigido a todo el mundo, ya que trata términos que, para un principiante en la materia, puede verlos complejos, sin embargo, para que no te pierdas nada y estemos en sintonía, considera tomar el Curso de Git donde aprenderás las bases, el uso de la terminal para practicar tus primeros comandos en Git.

Qué es Trunk Based Development

El desarrollo basado en tronco es una práctica de gestión de control de versiones en la que los desarrolladores fusionan pequeñas actualizaciones de forma frecuente en un “tronco” o rama principal (main).

Dado que esta práctica simplifica las fases de fusión e integración, ayuda a lograr la CI/CD (Continuous Integration / Continuous Deployment, siendo estos la Integración Continua y Despliegue Continuo) y, al mismo tiempo, aumenta la entrega de software y el rendimiento de la organización.

A medida que los sistemas de control de versiones se desarrollaron, surgieron varios estilos de desarrollo que permitieron a los programadores encontrar errores con más facilidad, crear código en paralelo con sus compañeros y acelerar el ritmo de publicación. Hoy en día, la mayoría de los programadores aprovechan uno de estos dos modelos de desarrollo para ofrecer software de calidad: Git Flow y desarrollo basado en troncos (Trunk Based Development).

Git Flow, que se popularizó primero, es un modelo de desarrollo más estricto en el que solo determinadas personas pueden aprobar los cambios en el código principal. Así se mantiene la calidad del código y se minimiza el número de errores. El desarrollo basado en troncos es un modelo más abierto, ya que todos los desarrolladores tienen acceso al código principal, lo que permite a los equipos iterar con rapidez y pone en práctica la CI y la CD. Sobre este último flujo, ya veremos más adelante cómo funciona a nivel teórico-práctico.

El desarrollo basado en troncos es otro modelo de trabajo, en este caso, más eficiente para DevOps, ya que permite agilizar el ciclo.

Utilidad de TBD

El desarrollo basado en troncos se ha convertido en una práctica habitual entre los equipos de DevOps y parte del ciclo de vida de DevOps, ya que simplifica las fases de fusión e integración. De hecho, el desarrollo basado en troncos es una práctica obligatoria de la CI y la CD. Permite a los desarrolladores crear ramas de corta duración con pequeñas confirmaciones, a diferencia de otras estrategias de ramas de funciones de larga duración. A medida que la complejidad del código base y el tamaño del equipo van creciendo, el desarrollo basado en troncos ayuda a mantener el flujo de publicación de la producción.

Como su nombre nos orienta, esta estrategia se basa en una sola rama denominada tronco, en los repositorios es llamada trunk o main, en adelante la llamaremos trunk. Esta rama será de larga duración ya que todos los procesos, ambientes, cambios, rollback entre otros estarán basados en dicha rama. En TBD no se tienen ramas alternas, ni bifurcaciones, ni cosas por el estilo, solo se trabaja con la rama trunk y cuando se tienen políticas de Pull Request se trabaja con el concepto de ramas features clonadas de trunk, siendo de carácter efímero y lo más cortas posibles.

Luego, la rama trunk es promovida donde se requiera, como por ejemplo en ambientes pre-productivos, producción, local, etc. Su versatilidad y respaldo la dan los tags o etiquetas, que hacen visible su momento en diferentes circunstancias del ciclo de vida del desarrollo de la aplicación en la que estemos trabajando.

Qué es Git Flow

Git Flow es un modelo alternativo de creación de ramas en Git que utiliza ramas de función de larga duración y varias ramas principales.

Para conocer más de la materia, específicamente de este flujo de trabajo, te recomiendo tomar el Curso de Git Flow Profesional, y si eres más curioso y deseas profundizar aún más, recomiendo que te documentes en este gran artículo sobre Estrategias de branching: Git Flow, GitLab Flow, OneFlow, GitHub Flow.

Utilidad de Git Flow

En Git Flow existen cinco tipos de ramas: main, develop, feature, release y hotfix. Te detallo una a una, cuál es su utilidad dentro del flujo.

Main

Es la rama principal de un repositorio, de hecho, es la que viene por omisión, integrada cuando se crea un repositorio. Sí, todo eso está bien, dirás, pero ¿cuál es su propósito?

El propósito de la rama main en el flujo de trabajo de Git, es contener código listo que se pueda liberar a producción (entorno donde el usuario final tiene acceso).

Esta rama es la que recibirá y combinará los cambios que provienen de otras ramas, todo depende por supuesto, de que sean suficientemente examinadas y probadas.

Develop

Esta rama es recomendable crearla al inicio de un proyecto, manteniéndose así, durante todo el proceso de desarrollo. Esta primeramente hereda los cambios de la rama main y continúa con su vida, es una copia exacta.

A media que progresa el tiempo, esta rama tiene que mantener los cambios de preproducción con características recién desarrolladas que están en proceso de ser probadas antes de que pasen a producción (a la rama main).

Ramas de soporte

Al desarrollar un proyecto con Git Flow, existen tres tipos de ramas de soporte con diferentes propósitos establecidos:

• feature (Característica)
• release (Lanzamiento)
• hotfix (Revisión)

Feature

Esta rama es el tipo de rama más común en Git Flow, debido a que se utiliza para agregar nuevas características a su código.

Cuando se haya que trabajar en una nueva característica, se inicia una rama feature fuera de la rama develop, y, a continuación, se combinan los cambios en la rama develop y desde la rama develop se encargarán de revisar las nuevas características que se han integrado en develop.

Release

La rama de lanzamiento debe utilizarse al preparar nuevas versiones de producción. Por lo general, el trabajo que se realiza en las ramas de lanzamiento se refiere a toques iniciales y errores menores específicos para lanzar nuevo código, con código que debe abordarse por separado de la rama de develop principal.

Hotfix

Esta es la rama de revisión, que se utiliza para abordar rápidamente los cambios necesarios en la rama principal.

La base de la rama revisión debe ser la rama main y debe fusionarse de nuevo en la rama main y develop. La fusión de los cambios de la rama hotfix (revisión) en la rama de develop es fundamental para garantizar que la corrección persista la próxima vez que se libere la rama main.

En realidad, Git Flow es una especie de idea abstracta de un flujo de trabajo de Git. Esto quiere decir que ordena qué tipo de ramas se deben configurar y cómo fusionarlas. Esta también es una herramienta y Git la trae integrada, lista para ser utilizada.

Iniciando con Git Flow

Este es el proceso inicial usando Git Flow, haciendo pasar por la inicialización de todo el modelo, desde el repositorio hasta nombrar las ramas centrales como las que tienen prefijo, donde este también da lugar a poder modificarlo.

# Se crea y se accede a un directorio.
$ mkdir GitFlow/
$ cd GitFlow/

# Se inicializa con el modelo que propone Git Flow.
$ git flow init
Initialized empty Git repository in C:/Users/Root/OneDrive/Documentos/Projects/Repositories/GitFlow/.git/

# Verifica que las ramas no hayan sido creadas, para crearlas.
No branches exist yet. Base branches must be created now.

# Definir cómo se llamará la rama principal o master.
Branch name for production releases: [master] main

# Definir cómo se llamará la rama develop.
Branch name for "next release" development: [develop] develop

# Definir los prefijos que tendrán cuando se cree una nueva rama.
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] 1

Hooks and filters directory? [C:/Users/Root/OneDrive/Documentos/Projects/Repositories/GitFlow/.git/hooks]

Todo esto lo solicita de forma dinámica desde la terminal. Notarán que después de la configuración, la rama seleccionada por omisión no es la rama main, sino más bien, la rama develop.

Gestionar características (feature)

• Se crea una nueva rama basada en develop, representando una feature llamada: server.
• Se cambia la rama que se está utilizando.
• Muestra cómo finalizar la característica.

$ git flow feature start server
Switched to a new branch 'feature/server'

Summary of actions:
- A new branch 'feature/server' was created, based on 'develop'
- You are now on branch 'feature/server'

Now, start committing on your feature. When done, use:

    git flow feature finish server

Finalizando una característica (feature)

Se finaliza en concreto la rama server con prefijo de feature/, siendo así queda de la siguiente manera: feature/server.

$ git flow feature finish server
Switched to branch 'develop'
Already up to date.
Deleted branch feature/server (was 1cad8ad).

Summary of actions:
- The feature branch 'feature/server' was merged into 'develop'
- Feature branch 'feature/server' has been locally deleted
- You are now on branch 'develop'

Las salidas de Git Flow son sencillas de leer, de comprender, pues llevan consigo una explicación como un resumen de acciones:

• La rama feature/server fue combinada con la rama develop.
• La feature/server ha sido removida.
• Me cambia de rama a la rama develop.

Con una sola instrucción realiza varias acciones que, con solo Git, sería un poco engorroso. Con solo git pasaría lo siguiente:

$ git checkout -b feature/server
Switched to a new branch 'feature/server').

$ git checkout develop
Switched to branch 'develop'

$ git merge feature/server
Already up to date.

$ git branch -D feature/server
Deleted branch feature/server (was 1cad8ad).

Estas han sido algunas pinceladas de lo que se puede hacer con Git Flow.

Comparación entre Trunk Based Development y Git Flow

Git Flow tiene más ramas de mayor duración y confirmaciones más grandes que el desarrollo basado en troncos. Según este modelo, los desarrolladores crean una rama de función y retrasan su fusión con la rama principal del tronco hasta que la función esté completa. Estas ramas de funciones de larga duración requieren más colaboración para fusionarlas, ya que presentan un mayor riesgo de desviarse de la rama troncal e introducir actualizaciones conflictivas.

Git Flow también tiene líneas de rama principales independientes para el desarrollo, las correcciones, las funciones y las publicaciones. Existen diferentes estrategias para fusionar las confirmaciones entre estas ramas. Al haber más ramas que gestionar y compaginar, suele haber más complejidad, por lo que se requieren sesiones adicionales de planificación y revisión por parte del equipo.

El desarrollo por tronco está mucho más simplificado, ya que se centra en la rama principal como fuente de correcciones y publicaciones. En este tipo de desarrollo, se da por sentado que la rama principal permanece estable, sin incidencias, y siempre está lista para la implementación.

Ventajas de Trunk Based Development sobre Git Flow

Por supuesto, Trunk Based Development tiene ventajas sobre Git Flow que debes conocer para que te aventures por el que mejor te convenga:

• El desarrollo basado en troncos es una práctica obligatoria para la integración continua. Si los procesos de desarrollo y prueba están automatizados, pero los desarrolladores trabajan en ramas de funciones aisladas y largas que se integran con poca frecuencia en una rama compartida, la integración continua no está a la altura de su potencial.

• El desarrollo basado en troncos disminuye la fricción de la integración del código. Cuando los desarrolladores terminan una tarea nueva, deben fusionar el código nuevo en la rama principal; pero no deben fusionar los cambios en el tronco hasta que hayan comprobado que los pueden compilar correctamente.

• Durante esta fase, pueden surgir conflictos si se han realizado modificaciones desde el inicio de la tarea nueva. En concreto, estos conflictos son cada vez más complejos a medida que los equipos de desarrollo crecen y la base de código se amplía. Esto ocurre cuando los desarrolladores crean ramas independientes que se desvían de la rama origen y otros desarrolladores están fusionando a la vez el código que se solapa. Por suerte, el modelo de desarrollo basado en troncos reduce estos conflictos.

Ventajas de Git Flow sobre Trunk Based Development

• Git Flow te permite enfocarte más en los proyectos de código abierto, ya que es posible comprobar con mayor precisión, todos los cambios que se han realizado y quién lo ha hecho, así como permitir los nuevos cambios, sin perder la gestión del mismo para retornar a versiones anteriores con menores conflictos.

• Viene bien cuando tienes colaboradores de cuál deseas conocer su trabajo más de cerca, observando cómo mejorar y hacer las cosas más eficientemente mediante la estructura que Git Flow provee.

• El estilo de desarrollo hace que la optimización de un proyecto con el flujo de trabajo Git Flow integrado, sea sencillo, donde siempre y cuando el tiempo no sea una limitación.

Conclusión, cuál elegir

Se han expuesto similitudes y puntos fuertes de Trunk Based Development y Git Flow, así como su comparación, ventajas y modo de uso de cada quien. Con esto, ya debes tener una mejor idea de por el cual decantarte. El elegirlo tiene que ver con la orientación de tu proyecto, donde elegirías al que se ajuste mejor a tus requerimientos, si estás en una vía de aprendizaje, entonces Git Flow te puede venir mejor, donde puedes entrenar a tu equipo y proponer un estilo de trabajo estrictamente estructurado, por otro lado Trunk Based Development está ganando más terreno en los últimos tiempos, más en el área de DevOps, por lo que si deseas un desarrollo ágil y despliegue continuo.