Manual (básico) de git-flow

Si eres programador seguramente conoceras git, el sistema de control de versiones más utilizado en la actualidad. Una de sus principales ventajas, es que se pueden crear ramas de una forma rápida y sencilla, lo que nos permite organizar nuestro trabajo para no interferir con el trabajo de los demás.

Sobre esa base, nace git-flow, una extensión a git para gestionar las ramas de nuestro repositorio de forma coordinada, conocida y útil.

Las bases de git-flow

Las bases principales de git-flow son:

• La rama principal (master) solo tiene código de producción.
• En la rama de desarrollo (develop) solo se guarda código que ya está probado y es funcional.
• El trabajo se organiza en funcionalidades (features) completas. Por ejemplo: «AMI de nagios», «login de usuarios», «etc.
• Junto con las funcionalidades, podemos tener cambios urgentes (hotfix), que solucionen problemas urgentes.
• Por último, tendremos versiones (releases), que son un grupo de características funcionales (por ejemplo, versión 1.1.4 o 2.0)

El objetivo es mantener siempre el código lo más aislado posible de las ramas donde trabajen más personas.

Trabajando con «features»

Las features serán la base de nuestro trabajo diario con git-flow. En resumen, creamos una rama a partir de develop, donde iremos trabajando. Una vez que hemos terminado añadiremos el código a la rama develop, crearemos una nueva feature y seguiremos el trabajo normal.

Los pasos para trabajar con una feature (por ejemplo usuarios), serían:

• Creamos la feature con git flow feature start usuarios
• Aquí, estaremos en la rama feature/usuarios (podemos verlo con el comando git branch)
• Trabajamos normalmente, y vamos guardando los cambios que vayamos haciendo con git commit -a
• Cuando hayamos terminado, es aconsejable actualizar nuestra rama con los cambios que hayan entrado en develop, con los comandos:
  • git checkout develop
  • git pull
  • git checkout feature/usuarios
  • git merge develop
• Cuando terminamos, ejecutamos el comando git flow feature finish usuarios, y todos los commit que hayamos hecho en ésta rama se integrarán en la rama develop.
• Por último ejecutamos git push para publicar nuestros cambios en el servidor.

Trabajando con «hotfix»

Un hotfix es un cambio urgente (normalmente asociado a un fallo de seguridad en nuestro código), por lo que aquí vamos a trabajar con código de la rama master, y al finalizar guardaremos los cambios en las ramas master y develop (para que el fallo se arregle en ambas).

Los comandos son iguales, pero cambiando feature por hotfix:

• git flow hotfix start errorgrave
• git flow hotfix finish errorgrave

Trabajando con «releases»

Una release o nueva versión de código se genera a partir de los cambios que hayan sido publicados en la rama develop, es decir, que nos limitamos a coger los cambios pendientes, y generamos una nueva versión con ellos.

El proceso es el mismo de siempre:

• git flow release start 1.1.0
• git flow release finish 1.1.0

Después de crear la nueva release, podemos editar los archivos necesarios para cambiar la versión, añadir información al README.md, etc

Usando git-flow de forma diaria.

Aunque cuando empezamos un proyecto siempre solemos pensar que no vamos a necesitar ramas ni nada complicado, y que podemos hacerlo todo en develop (o incluso en master), debemos acostumbrarnos a trabajar siempre con un sistema de ramas concreto, y en mi caso git-flow es la solución más óptima y cómoda de todas las que he probado.

Espero que os sea de tanta utilidad como a mi.