Git Flow es un modelo, una estrategia y también un workflow muy utilizado por los equipos de desarrollo y programación. Este se destaca por ayudar en la organización de la versión de un código.

Git Flow deja más organizado y seguro todo el proceso de creación de nuevos Features y Hotfixes dentro del código, evitando perder alguna información importante.

En este artículo, explicaremos todo sobre Git Flow y te mostraremos un flujo básico en el que este sistema actúa.

¿Qué es Git Flow y cuándo surgió?

Git Flow es una estrategia creada para mejorar la organización de Branchs (ramificaciones) dentro del repositorio y, de esta forma, dar más fluidez al proceso de nuevos Features y Releases.

El término, todavía, es reciente. Fue divulgado a través de una publicación del ingeniero de software holandés Vincent Driessen, en 2010. En esta, explicó con detalles cuál fue su idea al crear ese modelo para el uso de las Branchs.

¡No confundas Git Flow con Git!

Git es un modelo de control de versiones de código. Es posible interpretar este modelo algo parecido con un árbol y sus ramificaciones.

Si has utilizado Git, seguramente sabes que la Branch, llamada Master, es considerada la principal. Esta hace el trabajo de puente entre el repositorio y el servidor de producción.

Git Flow presenta una solución mucho más robusta, justamente para aquellos proyectos que van ganando cuerpo o que necesitan de actualizaciones constantemente. También es muy útil cuando existe una gran cantidad de personas trabajando o “commiteando” dentro de un repositorio.

El término “commitear” está relacionado con la actividad de commit, que significa someter las últimas alteraciones del código al repositorio, haciendo que estas se conviertan en parte de la versión principal.

Con el texto explicado, imagina un proyecto que envuelva a 40 desarrolladores. Es difícil visualizar la manera en la que todos los programadores web tratarían el código después de haber “commiteado” en la Master.

El trabajo para ajustar y recuperar datos originales sería mucha más demorado y arduo. Sin hablar del desorden que esto generaría.

También existen empresas que realizan estas actividades; sin embargo estas adoptan otras estrategias para no caer en la trampa de colocar algo en producción que no esté totalmente probado.

¿Cuál sería la forma correcta?

En un abordaje más genérico, es común utilizar la Master como la ramificación principal del repositorio. De esta forma, toda vez que sea necesario crear una nueva Feature o corregir algo, se creará una nueva Branch para cada caso.

Después de que esté concluido, se hace un Merge; es decir, la combinación de la Branch de Feature o la corrección con la Master.

Con Git Flow, algo parecido sucede; sin embargo, con una estructura de Branch un poco más compleja, pero que también ayuda mucho.

¿Cuál es el flujo estándar de un Git Flow?

Podemos separar Git Flow en dos tipos de Branch:

1. Principales: son las Branch Master y otra llamada Develop;
2. Soporte: son las conocidas como Feature, Release y Hotfix.

Para cada Branch, existen algunas reglas específicas para mantener la organización.

La Branch Master continúa siendo utilizada para enviar los commits de los Releases para la producción. Es a partir de esta que la Branch Develop puede ser creada, la cual contará con todos los Features estables que pasarán por el proceso Merge posteriormente para una Branch de Release.

Esto significa que para cada nueva Feature, una nueva Branch se crea.

Es importante destacar que la nomenclatura utilizada en Git Flow y también en otros Flows es estandarizada para facilitar el entendimiento y agilizar el trabajo de todos.

Pero, volviendo al tema, una Branch Feature será creada siempre a partir de la Develop y retornará vía Merge aún para la Develop; lo cual significa que después podrá ser removida.

Imagina que vas a crear una nueva Feature que es el formulario nuevo de contacto de un sitio web. Deberás nombrar la Branch con un nombre como “feature/new-contact-page”.

Una vez que tengas la nueva Feature incorporada en Develop, es necesario prepararla para entrar en producción, lo que no puede ser llevado apenas para la Master. Es necesario utilizar otra Branch de soporte, llamada Release.

Puede ser que, apenas después de la creación de un conjunto de nuevas Features, puedas tener un Release listo. Sin embargo, una vez que estos Features estén listos en el Develop, será posible unirlas en un Branch Release.

Con el Release listo para ir a Master, es el momento de crear una tag; o sea, una indicación, donde habrá una nueva versión de tu proyecto. Esto se hace en la Branch Master, después de Merge.

En cada Merge realizada en la Master, es necesario hacerla en la Branch Develop, para que sea reflejada en un Release taggeado y; después de eso, es posible que la Branch de este Release pueda ser eliminada.

Este es un flujo estándar de Git Flow; aunque nadie está libre de bugs o hasta problemas inesperados a lo largo de la producción. Y es aquí donde surge otra Branch de soporte, la llamada Hotfix.

Esta funciona como una Branch Release. La diferencia es que, en este caso, es utilizada para una acción más crítica.

Por esta razón, cuando una Hotfix es finalizada, esta será “Margeada” directamente en la Master. Esta también recibe una tag Master después del proceso y debe hacerse lo mismo en la Branch Develop.

Así, es posible mantener a los desarrolladores trabajando en sus Features, mientras que las Hotfix son creadas. De esta forma, las Branchs con Hotfix podrán ser removidas.

Otros abordajes de gestión de Branchs

Existen otros abordajes, además de Git Flow, que realizan la gestión de las Branchs en un proyecto. Un ejemplo, creado por GitHub en 2011, es llamado GitHub Flow. Este funciona bien en muchos casos, especialmente aquellos menos complejos.

Además de esto, para no quedar atrás, el equipo de GitLab también creó el GitLabFlow, en 2014. Otro nombre conocido es One Flow.

Git también cuenta con una extensión creada para agilizar todo el proceso; y así, pasar muchos comandos que deberían ser realizados muy pronto. La extensión se llama git-flow; lo que notablemente puede generar confusión con Git Flow. Así que debes poner atención.