Estrategias de branching: GitFlow, GitLab Flow, OneFlow, GitHub Flow

Si te dedicas a desarrollar software, es casi seguro que te has encontrado en una conversación, donde el tema central de la discusión es acerca de la mejor estrategia de branching que existe, en esa misma discusión te puedes encontrar a aquel desarrollador que prefiere GitFlow por sobre cualquier otra estrategia, o ese otro que dice que GitFlow es demasiado complicado y prefiere GitHub Flow por su simplicidad, además que asegura que es lo mejor para cualquier equipo y proyecto de desarrollo.

Seamos honestos, este tipo de discusiones no aportan ningún valor, ya que cuando las tenemos, nos alejamos del propósito por el cual existen tantas alternativas. Por esto, en las siguientes líneas, introduciré el concepto de las estrategias de branching y las distintas opciones que existen, como GitFlow, GitLab Flow, OneFlow y GitHub Flow, para que las puedas conocer y decidir cuál es la que mejor se ajusta a tu equipo o a la aplicación que quieras desarrollar.

Antes de ir directo a cada una de estas estrategias de branching, creo que es oportuno introducir algunos conceptos importantes.

Qué es Git

Git, es una herramienta open-source creada por Linus Torvalds en 2005, para facilitar la gestión de las versiones de código de manera fácil. Específicamente, Git es un sistema de control de versiones distribuido, lo que significa que toda la base de código y el historial se encuentran disponibles en la computadora de cada desarrollador, lo que permite que cada uno pueda gestionar de forma fácil la ramificación (branching) y fusión (merging) del código. En otras palabras, Git como control de versiones te permite realizar el seguimiento de cada cambio en tu código, además que te permite ver el historial de cambios cuando algo en tu código sale mal.

Un sistema de control de versiones como Git, facilita el trabajo de varios individuos permitiéndoles usar diferentes ramas (branches) como parte de un “árbol de archivos” y fusionar su código actualizado (hacer merge) en el branch principal (la única fuente de verdad) cuando esté realmente listo, es decir ha sido revisado probado y validado por algún compañero desarrollador a través de un code review.

Git se ha convertido en el estándar de facto para los sistemas de control de versiones en la industria del software. Si no fuera por Git y otros sistemas de control de versiones descentralizados, probablemente no estarías leyendo este artículo.

Si la “estrategia de branching” se ha convertido en un tema que genera mucha discusión, se debe a que Git hace que todo el proceso de branching y merging sea mucho más sencillo y económico que antes.

Si deseas conocer con más detalle qué es GIT, te invito a que te apuntes al Curso de Git que tenemos disponible aquí en OpenWebinars.

Sabemos que cada equipo y cada proyecto de desarrollo es diferente dado que cada uno abarca necesidades muy particulares. Aquí es donde entran en juego las diferentes estrategias de branching.

Qué es una estrategia de branching

Una “estrategia de branching” es una serie de reglas que aplica un equipo de desarrollo de software cuando necesita escribir un código para incorporar una nueva funcionalidad o hacer una corrección, fusionarlo y enviarlo al repositorio donde se encuentra alojado el resto del código del software en uso, por ejemplo, en un sistema de control de versiones como Git.

Los desarrolladores de software que trabajan en equipo en la misma base de código deben compartir sus cambios entre sí. Pero, ¿cómo pueden hacer esto de manera eficiente mientras evitan inconsistencias en el software?.

El objetivo de cualquier estrategia de branching es resolver precisamente ese problema, permitir que los equipos que trabajan juntos en la misma base de código fuente no afecten su código los unos a los otros.

Una estrategia de branching define como un equipo utiliza los branches para lograr un proceso de desarrollo concurrente, a través de un conjunto de reglas y convenciones que establecen:

• ¿Cuándo un desarrollador debe crear un branch?
• ¿De qué otro branch deben derivarse el nuevo branch?
• ¿Cuándo debe el desarrollador hacer merge?
• ¿Y a qué branch debería hacer el merge?

Por qué una estrategia de branching

Para los equipos que tienen cientos o miles de desarrolladores, si no tienen establecida una estrategia de branching, los procesos de branching y merging del código pueden resultar sumamente difíciles. Las fusiones incorrectas y las integraciones en etapas tardías pueden consumir mucho tiempo de los desarrolladores, retrasando potencialmente la entrega del software y releases futuros.

Una estrategia de branching garantiza que todos los miembros del equipo sigan el mismo proceso para realizar cambios en código. La estrategia correcta mejora la colaboración, la eficiencia y la precisión en el proceso de entrega de software, mientras que la estrategia incorrecta (o ninguna estrategia) conduce a muchos errores y problemas de integración, que se traducen en horas de trabajo, mucho esfuerzo y sobre todo pérdida de tiempo y dinero.

Para reducir estos problemas, una estrategia de branching debe buscar:

• Permitir a los desarrolladores optimizar su productividad.
• Habilitar el desarrollo en paralelo.
• Permitir un conjunto de releases estructurados y planificados.
• Proporcionar una ruta clara para promover los cambios del software al entorno de producción.
• Evolucionar y adaptarse a los cambios que se realizan a diario en el código.
• Admitir múltiples versiones de software.

Mainline Based vs. Branch based

Si quisiéramos agruparlas, las estrategias de branching más populares pueden dividirse en dos categorías:

Mainline Based

El principal problema que intenta resolver, es el de los builds rotos, es decir, que no compilan, porque en la mayoría de implementaciones de procesos de CI (integración continua), las pruebas de integración se realizan después de haber integrado el código. La solución que se propone, es por supuesto, hacer las pruebas de integración antes de la integración.

En esta estrategia, el elemento principal, lo que llamamos mainline, es el branch sobre el cual todos los desarrolladores trabajan. Este branch es comúnmente conocido como main o master en sistemas como Git, y se caracteriza porque siempre debe mantener un estado estable, donde estable significa que está en una forma lo suficientemente buena como para que todos los desarrolladores puedan trabajar en el código sin ser bloqueados por compilaciones fallidas.

Las organizaciones pequeñas o aquellas con sólidas prácticas de pruebas en todas las etapas del desarrollo de software, encuentran útil esta estrategia porque reduce la complejidad y alienta al que el equipo de desarrollo reconozca como su mayor prioridad, el hacer pruebas unitarias y arreglar los problemas que puedan causar que un build falle.

Esta estrategia, también conlleva riesgos. Por ejemplo, si contamos con varios equipos o un equipo grande, y se detecta un defecto complejo de resolver, mientras exista el defecto, es posible que los desarrolladores no puedan avanzar en su trabajo hasta que este sea corregido, lo que provoca pérdidas y retrasos innecesarios, que se agravan si la cultura de la organización muestra una tendencia de “culpar a las personas”.

Branch based

El uso de una estrategia Branch based, es decir basada en branches (ramas), permite a los desarrolladores crear una rama por cada desarrollo o tarea específica. Por ejemplo, podemos crear un branch por cada requerimiento o historia de usuario, lo que da más independencia y autonomía a los desarrolladores, ya que al trabajar cada uno en su propio branch, les permite trabajar su código por separado, que luego será integrado siguiendo el proceso que se haya establecido.

Por ejemplo, un equipo o persona podría estar trabajando en una corrección de un error en el código del módulo de ventas en su propio branch, mientras que otro podría estar creando un nuevo flujo de trabajo para el módulo de administración de clientes en otro branch totalmente distinto e independiente. Cada equipo puede trabajar de forma autónoma en su tarea asignada y hacer merge de los cambios en el branch principal (main, master) una vez hayan terminado el desarrollo y validado que todo funciona correctamente.

Estrategia de branching: GitFlow

La idea principal detrás de GitFlow es aislar el trabajo en diferentes tipos de branches, lo que le permite adaptarse muy bien al proceso colaborativo que necesita un equipo de desarrollo. GitFlow está basado principalmente en dos branches que tienen una vida infinita:

• master: contiene el código de producción.
• develop: contiene el código que ha finalizado desarrollo.

Adicional a estos branches principales, durante el desarrollo se crean otros branches de soporte que tienen una vida finita, es decir, existen mientras exista el desarrollo:

• feature: se crea a partir de develop cuando una nueva funcionalidad necesita ser desarrollada. Al finalizar el desarrollo se hace merge a develop nuevamente.
• release: se crea a partir de develop para preparar una nueva versión del código que debe ser liberada en producción. Al finalizar el desarrollo se hace merge a develop y a master.
• hotfix: se crea a partir de master cuando es necesario corregir un error detectado en producción de manera urgente. Al finalizar el desarrollo se hace merge a develop y a master.

Si deseas aprender más sobre GitFlow puedes apuntarte al Curso de Gitflow profesional que tenemos aquí en OpenWebinars.

Estrategia de branching: GitHub Flow

GitHub Flow, fue creado por GitHub y es conocido en la comunidad de desarrolladores como una alternativa simple y ligera a GitFlow. GitHub Flow se basa en un flujo de trabajo basado en branches que permite a equipos de desarrollo enfocarse principalmente en la entrega continua. A diferencia de Git Flow, no existen los branches de “releases”, ya que está pensado para que la implementación en producción ocurra con frecuencia, incluso varias veces al día si es posible.

En esta estrategia de branching, en el repositorio tenemos dos tipos de branches:

• main (o master): el branch de código principal, es el que contiene el código que está listo para producción.
• features: los branches de funcionalidades que permiten el desarrollo en paralelo.

Cuando utilizas GitHub Flow, existen seis principios que debemos seguir para asegurarnos de mantener un buen código listo para producción en todo momento:

• El código que está en _main debe poder implementarse en producción en cualquier momento._
• Cuando se crean nuevos _feature branches, se deben crear con nombres descriptivos. Por ejemplo, feature/add-new-account-type._
• Primero hacer commit en local, para luego hacer push al repositorio remoto.
• Abrir pull requests para solicitar feedback o ayuda, antes de hacer merge en el branch principal.
• Hacer merge del código en el branch _main, solo después de haber recibido aprobación del pull request._
• Una vez hecho el merge del código en _main, debe implementarse de inmediato, mejor si es en un entorno de producción._

GitHub Flow es ideal cuando necesitas mantener una única versión del código de producción.

Estrategia de branching: GitLab Flow

GitLab Flow se caracteriza por un flujo de trabajo bastante similar a GitHub Flow. La principal diferencia es que no solo permite el uso de release branches, sino que adiciona el uso de environment branches, por ejemplo, QA, Pre-Producción y Producción. Esto debido a que considera los casos donde una nueva funcionalidad no siempre puede implementarse en entornos de producción.

Al igual que GitHub Flow, GitLab Flow propone utilizar un master branch y feature branches. Una vez que terminamos el desarrollo en un feature branch, hacemos merge de nuevo con master.

Con respecto a los branches por entornos, estos se crean a partir de master cuando estamos listos para implementar nuestra aplicación. Tener diferentes ramas por entorno nos permite configurar herramientas de CI y CD para que se despliegue automáticamente los commits realizados en cada una de esas ramas. Si detectamos un problema crítico, lo solucionamos en el feature o en master, una vez corregido, hacemos merge con las ramas de los entornos.

Con respecto a los release branches, seguimos haciendo todo el trabajo en feature branches que luego hacemos merge a master al finalizar. Cuando nos aseguramos que master es lo suficientemente estable, es decir, ya hemos realizado todas las pruebas y corregido todos los errores, creamos un release branch que va a contener nuestra versión de código para desplegar. Si hay un problema crítico, primero lo solucionamos en master, realizamos cherry picking para hacer merge en release, es decir, seleccionamos las porciones de código que deseamos que contenga nuestro release.

Estrategia de branching: OneFlow

OneFlow fue concebido como una alternativa más simple a GitFlow. Sin embargo, “más simple” no quiere decir que permita hacer menos.

Con OneFlow es necesario tener un master branch que tendrá una vida infinita en el repositorio de código, además, cada nueva versión de producción debe basarse en la versión anterior, una condición que la mayoría de proyectos de software cumple. La mayor diferencia entre One Flow y Git Flow es que en OneFlow no existe develop.

Si bien el flujo de trabajo aboga por tener un branch de larga duración (master), eso no significa que no haya otros branches involucrados. Lo que sí es cierto es que cada uno de estos branches de soporte, por ejemplo, feature, hotfix, etc. deben ser de corta duración, se crean a partir de master y deben, una vez finalizado el desarrollo, volver a master. Los branches de soporte, facilitan el intercambio de código entre los desarrolladores y actúan como respaldo. Sin embargo, el historial de cambios de todo el código, siempre se encontrará en el master branch.

Seleccionando la mejor estrategia de branching

Dado que Git es una herramienta flexible, permite que los desarrolladores trabajen utilizando una amplia variedad de flujos de trabajo y estrategias, lo que hace que seleccionar alguna de entre todas las opciones disponibles no sea tan fácil, especialmente para quienes no tengan mucha experiencia en Git.

Entonces, después de ver todas estas opciones, _¿Qué estrategia de branching deberías elegir para tu equipo y su proyecto?, sinceramente, no es posible dar una respuesta única que sea correcta en todos los casos y para todos los equipos, sin embargo me gustaría dejarte un par de sugerencias que puedas tomar en cuenta cuando te enfrentes a esta pregunta:

• Empieza con lo más simple posible, solo avanza hacia enfoques más complejos cuando tengas la necesidad, no antes. Piensa en el acrónimo YAGNI (You Ain’t Gonna Need It), que significa no lo vas a necesitar.
• Elige una estrategia que reduzca los diferentes “tipos” de branches disponibles para que los desarrolladores elijan. Recuerda, menos es más.
• Considera la posibilidad de utilizar Feature flags, que también permite reducir la necesidad de crear branches de forma excesiva. _Un feature flag es un indicador que se utiliza para habilitar o deshabilitar una funcionalidad implementada en el código.

El hecho de que Git te permite crear fácilmente muchos branches, no significa que tengas que crearlos. Prefiere una estrategia que se base en tener menos branches y en utilizar feature flags para ocultar las características que no están listas para producción.

Y en tu equipo, ¿Cuál de estas estrategias de branching utilizan?