GitFlow debe ser parte de tu vida como programador

Uno de los pasos fundamentales de todo programador al iniciar un proyecto es crear un repositorio Git (por si no existe) para llevar el control de versiones del desarrollo. Realizar un desarrollo de software sin Git es una aventura muy peligrosa. Una analogía puede ser: Jugar un videojuego sin salvar la partida en ningún momento.

El proceso es relativamente sencillo: Se hacen modificaciones al código y Git detecta los cambios en los archivos. Se crea una rama para probar algo nuevo sin afectar el código original que está en la rama principal (Master). Cuando todo funcione, los cambios en la rama X se aplican en la rama principal (lo que se conoce como Merge).

¡Genial! Pero, ¿Qué es Git Flow?

Es un flujo de trabajo cuyo objetivo es optimizar el desarrollo y despliegues de los mismos en los ambientes productivos (cuya rama principal es Master). Existen otros flujos de trabajo con Git. Sin embargo, Git Flow es considerado uno de los Workflows más populares (por no decir «más popular») en el mundo y tú debes aplicarlo en todos tus desarrollos del mismo modo en que comes y respiras. ¿Por qué? Veamos:

Existen 6 ramas principales en Git Flow:

  • Main
  • Develop
  • Feature
  • Bugfix
  • Release
  • Hotfix

«Main» (Master):

Esta es la rama principal de Git que todos conocemos. En esta rama debe estar el código listo para despliegues a producción. No es puede hacer commits directamente a Main. La única forma en la que se puede alimentar esta rama es a través de Merges que vengan de la rama Release.

«Develop»:

Esta rama se crea al inicio del proyecto al configurar Git Flow. Esta rama contiene las nuevas funcionalidades y fixes que se encuentren en pruebas unitarias de desarrollo. Así como «Main», no se puede hacer commits directamente a Develop. Para poder alimentar esta rama, se debe realizar Merge que vengan de las ramas «Feature».

«Feature»:

Las ramas llamadas ‘feature’ son ramas de soporte. Esta rama (A diferencia de Main y Develop), no se crea al inicio del proyecto. La rama nace desde Develop al momento que se desee desarrollar una nueva funcionalidad. Una vez que se culmina dicho desarrollo, esta rama se une a Develop.

«Bugfix»:

Estas ramas nacen a partir de Develop. El objetivo de estas ramas es corregir errores encontrados en pruebas unitarias o alguna otra etapa del desarrollo inicial. Cuando se corrige el bug, esta rama se une a develop y finaliza su vida.

«Release»:

Las Ramas Releases se usan al momento de preparar el código para el despliegue. Es decir, justo antes de ir a Producción. En este punto, el objetivo es hacer una revisión del código del proyecto, corregir posibles errores que se hayan escapado de las pruebas unitarias, hacer unos retoques finales, etc. Todas las ramas Releases nacen de la rama Develop.

«Hotfix»:

Estas ramas se usan únicamente cuando se consigue algún error en producción (Main) que debe atenderse con urgencia. Es la forma más cercana de llevar nuevo código a producción debido a su urgencia. Estas ramas nacen a partir de producción.

Representación Gráfica de un Repositorio usando Git Flow

Como se puede apreciar en la imagen anterior, las ramas Main y Develop no reciben un commit propio jamás. Los commits en dichas ramas son Merges de otras : Features y Bugfix para Develop, así como Hotfix y Releases para Main.

El propósito de este flujo es tener un mayor control de despliegue de proyectos con Git. Este flujo de trabajo funciona sin importar la cantidad de involucrados. En lo personal, todos mis proyectos de desarrollo los llevo con Git Flow.