Gitflow: Estructurando Git

Si hace un mes os iniciamos en el mundo del control de versiones con Git, hoy queremos ampliar estos conocimientos con Gitflow. Suena guay ¿verdad?, pero ¿y eso qué es?, ¿usar Git con estilo?, ¿rimar los commits?, ¿entrar en una batalla de versos ante un conflicto entre ramas? Si bien suena divertido, nada que ver (lo siento).

Gitflow es una forma de estructurar el flujo de trabajo cuando usamos Git. Es decir, fija una estructura estricta de ramas secundarias a las que asigna un rol específico, así como un momento y modo de interactuar con las ramas principales: develop y master.

Ramas principales

Estas ramas son las que están directamente relacionadas con el código en producción. Por un lado master contiene la última versión del proyecto y por ello es la que está en producción, y develop contiene el último estado del desarrollo (incluyendo todos los commits que se han hecho para llegar a dicho estado).

Para aclarar: develop es el master de pruebas. En develop podemos ir añadiendo los cambios realizados en otras ramas o en esta misma y ver como reacciona el código ante estos cambios. Así, antes de pasarlos a master, podremos ver si algo se rompe y podría causar errores en producción, que recordemos es el código que se encuentra en master.

Definidas estas ramas, pasemos a las nuevas, las llamadas ramas de soporte.

Ramas secundarias o de soporte

Gitflow define tres ramas distintas, cada una con un rol específico:

• Feature: Se usan para desarrollar nuevas funcionalidades. Se crean a partir de develop y se incorporan a esta (haremos merge con develop) cuando terminemos de desarrollar esta funcionalidad. Por ello nunca se relacionan con master.
• Releases: Se usan para lanzar una nueva versión del proyecto, por ejemplo tras desarrollar unas cuantas funcionalidades y querer preparar el paso a producción de estos cambios. Se crean a partir de develop, que contiene las nuevas funcionalidades, y se incorporan a master y develop, para dejar las ramas principales en el mismo estado.
• Hotfix: Se usan para introducir cambios rápidos en producción, por ejemplo para corregir un error puntual o rectificar algún aspecto sencillo. Cabe hacer hincapié en esto, los cambios que introduzcamos deben ser sencillos y rápidos; si se necesita de un desarrollo mínimo la rama adecuada será feature, para poder controlar cómo reaccionará el código ante esos cambios. Las ramas hotfix se crean a partir de master y se incorporan a master y develop, de nuevo para garantizar la igualdad de estado en ambas.

Y como una imagen vale más que mil palabras, os dejo esta que esquematiza muy bien lo explicado. Pista: cada círculo es un commit y las líneas representan el final de una rama.

Instalación

El comando de instalación en Ubuntu o sistemas Linux es apt-get install git-flow y podemos ejecutarlo sin importar el directorio en que nos encontremos.

Y para inicializarlo podemos usar, en el directorio raíz de nuestro proyecto, los siguientes comandos:

• git flow init → Este nos permite definir los nombres de las ramas de soporte, si bien a mi juicio personal y totalmente subjetivo la opción más adecuada para empezar a trabajar es dejar las opciones por defecto, para ir familiarizándonos con la estructura y nomenclatura de Gitflow. Además este también permite definir el prefijo de las versiones que vayamos lanzando.
• git flow init -d → Este inicializa Gitflow con las opciones por defecto, es decir con los nombres de las ramas de soporte antes mencionadas y sin prefijo en las versiones. Es el comando rápido si no queremos cambiar la configuración por defecto al inicializar.

Mencionar que todo esto no entrará en conflicto con Git y sus comandos, que podremos seguir usando con total normalidad, ya que se trata de una ampliación.

Manos a la rama: Trabajando con Gitflow

La estructura básica para ejecutar comandos es

git flow tipo_rama_de_soporte accion nombre_de_rama

• Tipo de rama de soporte: Son las ya mencionadas feature, release y hotfix.
• Acción:
  • start para crear una nueva rama en local. Al ejecutarlo directamente te cambia a ella, por lo que no será necesario hacer un checkout a esta nueva rama.
  • finish para finalizarla. Recordar en este punto que, dependiendo del tipo de rama de soporte con la que estemos trabajando, esto tendrá diferentes consecuencias, incorporando los cambios a develop y/o master, cambiando a estas y eliminando la rama de soporte (tanto en local como en remoto). Por ejemplo finalizar una feature incorporará los cambios a develop, nos situará en develop yeliminará la rama feature.
  • publish para subirla a un repositorio remoto. Esta acción en principio será la menos utilizada, o por lo menos yo es la que menos gasto, ya que las ramas “online” son o deben ser las principales, pero puede suceder que necesitemos que alguna de las de soporte estén disponibles en remoto.
• Nombre de rama: Aquí podemos indicarle la que más nos guste, no hay límites para la imaginación. Aunque si aceptáis un consejo, currarse el naming de las ramas os ayudará a clarificar en qué estáis trabajando, ya sea para acordaros de ello después de un tiempo si la dejáis de lado o para tener una especie de lista de las funcionalidades en desarrollo.

Unos apuntes especiales sobre las ramas feature que está bien saber son: por un lado, que podemos listar las ramas features actuales con git flow feature (de ahí la importancia de los nombres); y por otro que, para navegar entre ramas feature o volver a ellas después de una pausa, podemos usar git flow feature checkout nombre_rama, de modo que concretamos que la rama a la que queremos volver es del tipo indicado.

Bibliografía:

• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
• http://codeloveandboards.com/blog/2013/04/06/automatiza-tu-manera-de-usar-git-con-git-flow/