Introducción a Gitflow

Entender la lógica de git y aprender sus operaciones básicas no es una tarea difícil. Sin embargo, utilizarlo de forma eficiente y fluida es otro tema. Una de las preguntas más frecuentes de los novatos es como diseñar el flujo de trabajo (workflow) en git. En este artículo vamos a hablar sobre un workflow llamado Gitflow. Desde que surgió en los últimos años en la comunidad de git, tuvo inmediatamente gran aceptación y llegó a ser un punto de partida para la creación de los workflows particulares en muchos proyectos.

En el artículo vamos a usar un enfoque pragmático. Partiendo por el workflow trivial, la línea secuencial de una sola rama, se pasa por una serie de mejoras graduales, resolviendo problemas puntuales uno por uno y llegando finalmente a un flujo git genérico, pero flexible y poderoso: Gitflow.

La línea secuencial

En la siguiente figura vemos un ejemplo de una serie de commits realizados en la rama principal de git (master). Este flujo simple es perfectamente válido y usable en los proyectos.

Linea secuencial del Gitflow

Sin embargo, el mismo sufre de varios problemas, que le impiden apoyar un proyecto real de forma eficiente. Como se ve en el gráfico, la rama master contiene los commits que son distintos en su naturaleza (versiones estables, correcciones de errores, etc), todos mezclados y desordenados. Con el avance del proyecto y crecimiento del repositorio pronto llegaríamos a una larga línea secuencial de los aportes al proyecto sin estructura alguna.

Esto no sólo es difícil de entender y seguir, sino nos haría complicadas y hasta imposibles, las tareas comunes tales como testing o agregación de nuevas funcionalidades.

La rama de desarrollo

La primera mejora sobre la línea secuencial es la introducción de la rama de desarrollo (develop). La idea detrás de ella es aliviar la rama maestra, liberándolas de la mayoría de los commits, y reservarla únicamente para las versiones productivas:

Gitflow con rama de desarrollo

Ahora la rama maestra es muy liviana, y muestra de una forma fiel y clara la historia de las versiones productivas del sistema bajo desarrollo. Todos los otros commits trasladamos a la nueva rama.

Con esta mejora hemos resuelto la visibilidad y gestión de las versiones productivas, pero al mismo tiempo hemos corrido la mayoría de los otros problemas a otro nivel. Todos los commits de la rama de desarrollo siguen mezclados y dificiles de seguir.

Desarrollo basado en funcionalidades

Aprovechando la ramificación e integración, altamente eficientes en git, vamos a estructurar el contenido de la rama de desarrollo en base a las funcionalidades del sistema. Para cada nueva funcionalidad vamos a crear una rama nueva, que vive hasta finalizar su implementación. En este momento la vamos a integrar de vuelta a la rama de desarrollo:

Gitflow con ramas basadas en funcionalidades

Esta nueva estructura de ramas refleja de una forma clara las funcionalidades, los componentes u otros módulos del sistema bajo desarrollo. Además, se apoya el trabajo grupal, pues varias funcionalidades nuevas se pueden implementar simultáneamente, sin perder control o claridad.

Sin embargo, aún queda espacio de mejoramiento. Entre otras cosas, el workflow actual no apoya bien las actividades de las pruebas y aseguramiento de la calidad.

Pruebas y aseguramiento de la calidad

Para las dichas tareas vamos a crear otra nueva rama, llamada release. Esta acepta las versiones candidatas para la producción (beta versiones) permitiendo su aislamiento y pruebas de aceptación. Todas las eventuales correcciones de los errores detectados vamos a realizar en la misma rama release, hasta lograr una versión estable, lista para la producción:

Gitflow para QA

Esta gran mejora permite no sólo un proceso de testing comprensible, sino también lo desacopla del desarrollo como tal. En consecuencia, el desarrollo de nuevas funcionalidades puede seguir  simultáneamente con el testing de una versión previa e independiente de él.

Corrección de los errores críticos

La última mejora del workflow abarca otra situación muy común en desarrollo: resolución de los errores críticos en los sistemas en producción. La rama release no se puede usar fácilmente para esta tarea, pués ella en cualquier momento puede contener una versión beta, aún no lista para la liberación. Una solución natural es bifurcar una rama especial, directamente de la rama maestra, aislar así el error, corregirlo e integrar de vuelta a la misma rama en forma de una nueva versión en producción:

Gitflow para la corrección de errores críticos

Conclusión

El último diagrama demuestra todos los elementos importantes del Gitflow. Cabe destacar que éste se debería tomar como referencia y ajustar a las necesidades propias. En caso de equipos muy pequeños se pueden quitar algunas ramas y simplificar el flujo. En proyectos muy grandes se pueden requerir ramas adicionales u otras reglas propias.

La flexibilidad de git y particularmente la eficiencia de su ramificación e integración dejan una libertad casi infinita.

Si necesita más información de lo que ofrece Craftware, por favor siga los siguientes enlaces:

Asesorías Git

Curso de Git

Leave a Reply