Control de versiones con Git: Estrategias Populares

En la actualidad, cuando pensamos en control de versiones para un proyecto de software, comúnmente pensamos en Git, una herramienta creada en 2005. A diferencia de otros sistemas de control de versiones, Git no tiene una preferencia por una estrategia tan definida.

A nivel individual, esto no es problema, pero al encontrarnos en proyectos complejos una de las tareas iniciales debe ser definir el flujo de trabajo que se manejará para Git. Esto incluye definir formato para los nombres de ramas, cuando se crearán ramas, nombres de commits, estrategias para merge, y otros detalles que ayuden a mantener un historial de cambios limpio y ordenado.

Entre algunas de las estrategias conocidas están el flujo centralizado, GitFlow, GitHub Flow, feature flow, y trunk-based. En este artículo vamos a resaltar únicamente las estrategias más conocidas y que permiten una mejor colaboración cuando se trata de trabajo en equipo.

Trunk-based Development (TBD)

En el desarrollo trunk-based, se tiene una única rama principal (normalmente main), en la cual se van incluyendo los cambios. Las demás ramas consisten de cambios pequeños que se van incluyendo frecuentemente.

El alcance de las tareas para este tipo de desarrollo suele ser reducido para incrementar la frecuencia con la que los cambios se van incluyendo en la rama main. En algunos casos, incluso, los cambios se realizan directamente en main.

En la perspectiva del desarrollador, no mucho cambia aparte de la utilización de convenciones de nombre para estas ramas cortas (ejemplo, tarea/ID-123, fix/ID-456). Lo único a tener en cuenta es que al tener una única rama estable, las funcionalidades que se vayan incluyendo deben mantenerse ocultas mediante mecanismos como banderas de funcionalidad (feature flags) hasta el momento de su despliegue formal.

git checkout main
git checkout -b tarea/ID-124
echo "Cambio" >> readme.md
git add readme.md
git commit -m "Descripción del cambio"
git push origin tarea/ID-124 # Se suben lo cambios al repositorio

# Para hacer merge desde otra máquina
git checkout main
git pull origin main
git fetch -a # Hace fetch a todas las ramas, también puede usarse git fetch origin tarea/ID-124
git merge tarea/ID-124
git push origin main

GitFlow

GitFlow es un flujo basado en ramas de funcionalidad, también conocidas como feature branches. En esta estrategia, no solo cambia como trabaja el desarrollador, sino también el proceso de despliegue de la aplicación.

• Los cambios se realizan a partir de una rama develop, en feature branches por tarea, siguiendo un formato para el nombre de la rama.
• En la rama de release, se incluyen los cambios que se tenían previamente en develop y se envían a main y develop para luego identificar la versión con una etiqueta.
• Para arreglos, se crean ramas de hotfix que son directamente enviadas a main y develop, de forma similar al caso de la rama release. Asegurando tener los arreglos de errores en la rama que utilizan los desarrolladores para basar sus cambios.

GitFlow tiene una estrategia bastante definida y reduce la cantidad de conflictos en comparación a TBD; todo esto a cambio de complejidad en los despliegues.

# Ejemplo saltando los pasos de push/pull
git checkout develop
git checkout -b tarea/ID-123
echo "ID-123" >> readme.md
git commit -m "Tarea 123"
git merge tarea/ID-123
git checkout -b release-1 # Branch para release
git checkout main # Preparación cuando todos los cambios estén en release
git merge release-1
git checkout -b hotfix/ID-456 # hotfix luego del release
echo "ID-456" >> readme.md
git add readme.md
git commit -m "Hotfix 456"
git checkout main
git merge hotfix/ID-456 # Release directo del hotfix
git checkout develop
git merge main # Actualización de develop para incluir el hotfix

GitHub Flow

GitHub Flow es una alternativa más simple a GitFlow, donde se trabaja con una rama main, y a partir de ella se realizan todos los cambios, ya sean por feature branches o ramas de hotfix. En este caso, las ramas suelen incluir cambios más extensos que los encontrados en TBD, normalmente acompañado de técnicas de CI/CD para interactuar con la rama principal.

Su complejidad es menor en comparación con GitFlow; sin embargo, es más propenso a conflictos, y se posee menos controles respecto a qué pasar a ser desplegado. La manera de contrarrestarlo es mediante ciclos de desarrollo y despliegue más cortos, promoviendo que los desarrolladores mantengan sus cambios actualizados con la rama principal.

Para garantizar la estabilidad, es común encontrar la implementación de medidas intermedias como la inclusión de ramas develop con su propio ambiente y el uso de etiquetas para la gestión de versiones. Además, algo común para los equipos ágiles con ciclos de desarrollo cortos, es la inclusión de pruebas a nivel de ramas de funcionalidad.

git checkout main
git checkout -b tarea/ID-125
echo "ID-125" >> readme.md
git commit -m "Tarea 125"
git push origin tarea/ID-125

# Los cambios se incluyen en main mediante pull request pasando por el CI
git checkout main
git pull origin main
git tag v1 # Nuevo tag con los cambios de la última tarea
git push origin v1 # Con el nuevo tag ocurre el despliegue

Cómo determinar la estrategia correcta

Existen más estrategias que las mencionadas aquí y cada una tiene sus propios escenarios en las que son más útiles, ninguna cubre todos los proyectos. Para tomar la decisión de cuál utilizar, nos basamos en factores como el tamaño y madurez del equipo, madurez del software y su estructura, ciclo de release que se espera manejar, y expectativas de estabilidad.

Como guía, estas son las características que se buscan para las estrategias de este artículo:

• Trunk-Based Development: para equipos pequeños, donde la complejidad del proyecto es baja y la estabilidad no es prioridad. Un ejemplo, serían herramientas de línea de comando o algunas librerías sencillas. También es puede verse en proyectos que están migrando de otros sistemas de control de versiones, pero que no reciben cambios frecuentes.
• GitFlow: equipos maduros, con flujos de trabajo bien definidos. Esta estrategia se beneficia de mayor estabilidad en los despliegues, siendo elegido para proyectos complejos o con funcionalidades críticas.
• GitHub Flow: más común en equipos chicos o medianos, donde la complejidad del proyecto puede variar. Es la opción favorita de muchos equipos ágiles por su simplicidad y ritmo rápido. Se complementa realmente bien del uso de CI.

Rootstack, agencia de desarrollo de software con experiencia en más de 60 tecnologías y un equipo de expertos certificados que podrán ayudarte en tu resurgir profesional.

Te recomendamos en video