A la hora de trabajar con git hay varias estrategias que podemos seguir. Cada una tiene sus pros y sus contras, hoy vamos a ver las dos más populares Git Flow y GitHub Flow.
Tabla de contenidos
1 - Qué es GitFlow?
Git Flow es una estrategia de crear branches la cual consiste en tener tu repositorio git, con el branch main. Este branch main como branch principal.
Además tenemos otro branch, el cual es development (o dev) que es de donde los desarrolladores sacan sus branches. Estos branches normalmente son los tickets del sistema de tickets que utilices. Y cuando terminas haces el merge desde tu branch de la tarea, normalmente llamado feature, en el branch de dev.
La idea de este branch de desarrollo es que otros equipos o miembros puedan ir implementando sus funcionalidades y haciendo el merge en el branch de desarrollo.
Luego llegado un punto, se quieren desplegar las funcionalidades a producción y para ello tenemos otro tipo de branch, al cual llamamos release.
Un término muy común es decir “cortar la release”, eso significa que todo el código que hay en el branch de desarrollo va a ir a producción y una vez se corta dicha release se sigue haciendo merge en el branch de desarrollo.
El proceso de release consiste en varios pasos. El primero es desplegar en los entornos de pre producción (tambien llamados Staging o UAT). En la gran mayoría de empresas, podrás desplegar en el entorno de desarrollo/test desde el branch de development o incluso una feature branch. Pero para pre producción suele hacer falta tener una release.
Así que el primer paso es desplegar en pre-producción y ejecutar los tests necesarios para asegurarnos de que todo funciona bien.
Si algo falla podemos hacer cambios en el propio branch de release, pero es importante que luego los volvamos a introducir en el branch de desarrollo.
Cuando todo funciona y despliegas a producción, lo que haces es aplicar los cambios en el main branch.
Como puedes observar también le estamos poniendo una etiqueta o un tag cada vez que hacemos un merge en el branch de release le ponemos una etiqueta, esto se hace para identificar el número de la versión, y cierta información sobre el cambio.
Finalmente, pero no menos importante, cuando trabajamos con Git Flow debemos hacer uso de los hotfixes ya hice un post hace tiempo sobre el uso de hotfixes y cómo hacerlo en el propio git, así que lo tendréis enlazado. Pero resumiendo, puede pasar que tengamos un bug en producción que es urgente, y git flow es un proceso bastante lento, así que lo que se hace es sacar un branch, llamado hotfix desde main donde arreglamos el bug y lo volvemos a aplicar, tanto a main, como al branch de desarrollo.
2 - GitHub flow
Para ser sinceros no tenía ni idea de que este modelo se llamaba github flow, ya que cuando he tenido que nombrarlo siempre lo he descrito en vez de decir su nombre.
La clave de este proceso es que cada commit que se hace, tiene o debe estar capacitado para ir a producción.
Ojo, esto no significa que los miembros del equipo trabajan directamente en main, no. Esto significa que cuando hay un merge a main, ese código puede ir a producción sin romper nada.
En este modelo tenemos un branch principal, main, y de ahí sacamos features las cuales debemos asumir que se despliegan en producción.
Con esto en mente, puedes pensar que si una funcionalidad es grande tendremos problemas porque vas a tener branches en paralelo durante mucho tiempo, pero la realidad es que eso no es así ya que al implementar este flujo de trabajo implementamos funcionalidades como las feature flags.
Y otro punto clave es que con este flujo, vamos a promover entre los miembros del equipo a hacer tareas pequeñas, las cuales lanzaran la pipeline, por lo que el código va a estar testeado continuamente, habilitando la integración continua y el despliegue continuo (CICD)
3 - ¿Trabajar con Git Flow en 2025?
La gran pregunta es si debemos utilizar Git Flow en la actualidad. Yo iré directo y al grano, hasta hace un tiempo llevaba sin trabajar con git flow años y pensaba que estaba completamente erradicado de todo proyecto que no fuera legacy. Pero la realidad es que no, las empresas siguen utilizando este modelo porque tiene sentido.
Con esto quiero decir que en el desarrollo moderno de microservicios y sistemas distribuidos gitFlow puro no tiene sentido ni cabida y si lo implementas lo que haces es tener una gran cantidad de pasos para desplegar funcionalidades muy pequeñas o cambios minúsculos. Pero como todo es depende como se trabaje con el, puedes tener simplemente una rama main, donde todo tu CI/CD va en develop hasta pre producción y para ir a producción hay que mergear en main.
Este proceso puede estar automatizado o puede ser manual y es un proceso híbrido donde en caso de necesitarlo, podremos hacer un hotfix.
Git Flow, pese a que se puede, no está pensado principalmente para tener continuous delivery y continuous integration, está pensado para cuando una aplicación tiene un desarrollo más al estilo waterfall, que ojo, muchas aplicaciones y sistemas funcionan de esta manera, sobre todo si tienen mas de cierta cantidad de años.
Otra opción donde yo veo Git Flow muy útil es cuando tenemos que soportar múltiples versiones, por ejemplo, cliente 1 está en la versión 3.5, cliente 5 está en la versión 2.9, donde ahí sí es útil. Pero cualquiera que haya trabajado en empresas con configuraciones así para empresas, sabrá que se vuelven un caos muy rápido. Y por supuesto, ningún producto SaaS en la nube puede funcionar con múltiples versiones.
