Metodología de trabajo Git Flow. Divide tu proyecto en ramas y vencerás.

Metodología de trabajo Git Flow

Uno de los factores que tienes que tener en cuenta en tu trabajo, ya lo hagas tú solo o dentro de un equipo, es la metodología que vas a utilizar a la hora de desarrollar y mantener un proyecto. De todas las que hay, mi favorita es Git Flow, y en este artículo te voy a contar en qué consiste.

Por si no has escuchado hablar nunca de ella, te diré que Git Flow es una metodología de trabajo basada en Git, creada por Vincent Driessen. Dicha metodología, define un modelo de ramificación estricto, diseñado alrededor del proyecto. Esto proporciona un marco robusto para gestionar proyectos más grandes.

Metodología de trabajo Git Flow

Git Flow es ideal para proyectos que tienen un ciclo de lanzamiento programado. Esta metodología de trabajo no agrega ningún concepto o comando nuevo más allá de los que se utilizan comúnmente cuando trabajas con Git (status, add, commit, checkout, merge, pull y push). Lo que sí hace, es asignar roles muy específicos a diferentes ramas y define cómo y cuándo deben interactuar.

Vamos a ver, las distintas ramas con las que vamos a trabajar, y para qué sirve cada una de ellas.

Ramas principal y de desarrollo: master y dev

Cuando trabajas con Git Flow, en lugar de trabajar solamente con la rama master (cosa que es muy poco recomendable hacer), utilizas dos ramas para registrar el historial del proyecto: master y dev. Mientras que la primera de ellas contiene el historial de lanzamiento oficial, y por tanto, el código que está en producción, la rama dev sirve como una rama de integración de características.

Ramas de características: feature

Este tipo de ramas, se utilizan para añadir nuevas características a tu proyecto, en futuras versiones. Estas ramas, dependerán de la rama dev y se creará una por cada característica que se quiera incorporar al proyecto.

Como la mejor forma de explicar las cosas, es con un ejemplo, imagina que tienes un blog en el que quieres incorporar una funcionalidad para compartir tus artículos en Redes Sociales. Para ello, sobre tu rama dev, ejecutarás el siguiente comando de Git:

git checkout -b feature-share_social_network

Si te das cuenta, lo que he hecho ha sido crear una nueva rama, en la que he indicado que es una característica (feature- y una descripción de para qué va a servir (-share_social_network). De esta forma, podremos identificarla rápidamente sin necesidad de examinar el código, además de facilitar el trabajo en equipo.

De ahora en adelante, todo el desarrollo que hagas para esta característica, lo harás sobre esta rama.

Ramas de corrección de errores: hotfix

Mientras que las ramas feature las vas a utilizar para planificar nuevas características para tu proyecto (o mejora de las existentes), hotfix servirán para corregir errores que se hayan encontrado en el código (ya sean de rendimiento o de seguridad) y que no puedan esperar a una nueva versión para ser arreglados.

Ahora, imagina que tu blog cuenta con un formulario de contacto, a través del cual, tus lectores te envían dudas. Un día, por alguna razón, detectas que el formulario está fallando, así que tienes que ponerle solución rápidamente, antes de que tus seguidores piensen que no les contestas a sus mensajes y pasas de ellos. En esta ocasión, crearás una nueva rama, de esta forma:

git checkout -b hotfix-contact_form-001

Vamos a ver con detenimiento el por qué de este nombre para la rama:

  • En primer lugar, se trata de una rama de corrección de errores, por lo que debe llevar el prefijo hotfix- para que se identifique rápidamente su objetivo.
  • A continuación, como se trata de una incidencia relacionada con el formulario de contacto, le añades el nombre de la característica que vas a arreglar (contact_form).
  • Por último, como no sabes si en un futuro aparecerá otro error en el formulario de contacto, te sugiero que añadas un código. Así, la siguiente incidencia relacionada con esta característica será la -002, luego la -003,…

Una vez hayas reparado el fallo y testado para que no vuelva a ocurrir, lo tienes que incorporar a la rama dev. Para ello, tendrás que ejecutar la siguiente secuencia de comandos Git (dando por hecho que estas en la rama de la incidencia):

git add [nombre-de-los-archivos]
git commit -m "hotfix-contact_form-001"
git checkout dev
git pull
git merge hotfix-contact_form-001
git push

Los comandos que acabas de ejecutar, sirven para (en el orden de ejecución):

  • Indicar los archivos que vas a subir al repositorio y a desplegar.
  • Comitear los archivos. Como puedes ver, en tu commit, pones el nombre de la rama para que en tu historial quede reflejado que se trata de la corrección de un error relacionado con el formulario de contacto.
  • Cambiar a la rama dev.
  • Incorporar posibles cambios que hayas podido hacer en la rama dev a la rama hotfix-contact_form-001. Esto, además de para tener todo el proyecto actualizado en tu rama de corrección de errores, te puede servir también para comprobar si uno de los archivos que has modificado para reparar la incidencia ha sido modificado en otra rama, y si sus cambios entran en conflicto con los tuyos.
  • Incorporar los cambios hechos en el código para resolver la incidencia a la rama dev.
  • Subir los cambios al repositorio.

Una vez tu código haya sido probado en dev, estará listo para sacarlo a producción, por lo que solo tendrás que incorporarlo a la rama master, con una secuencia similar a la anterior:

git add [nombre-de-los-archivos]
git commit -m "hotfix-contact_form-001"
git checkout master
git pull
git merge dev
git push
git checkout dev
git merge master

Fíjate, que en esta secuencia, además, has vuelto a cambiar a la rama dev, ya que en la rama master nunca se trabaja, y has incorporado todos los posibles cambios que hubiese en la rama principal, para así tener tu rama de desarrollo actualizada.

Cuando tu código haya sido desplegado a producción y probado, solo te queda eliminar la rama que has estado utilizando, pues ya no la vas a necesitar más. Para ello, usa este comando, desde tu rama dev:

git branch -D hotfix-contact_form-001

Ramas de versiones y lanzamiento: release

En estas ramas es donde vas a preparar todo para el lanzamiento de una nueva versión para tu proyecto, o dicho de otra forma, donde incorporarás todas las características de las ramas feature y las terminarás de testar antes de sacarlas a producción.

Para ello, primero tienes que crear tu rama de lanzamiento, de la siguiente forma:

git checkout -b release-v1_1

Como ya podrás imaginar, después de ver como se han formado los nombres de otras ramas, en esta ocasión estarás indicando que se trata de una rama de lanzamiento (release-) y que la versión que se va a lanzar va a ser la 1.1 (v1_1).

Siguiendo con nuestro ejemplo de la funcionalidad para compartir en Redes Sociales, y suponiendo que ya está testada, procederemos a incorporarla con la rama de lanzamiento, con una secuencia de comandos Git similar a la de la corrección de errores:

git add [nombre-de-los-archivos]
git commit -m "feature-share_social_network"
git checkout release-v1_1
git pull
git merge feature-share_social_network
git push

Cuando hayan sido incorporadas todas estas características a la rama de desarrollo, y tras comprobar que no hay ningún conflicto, deberás incorporar la rama release- a la rama dev:

git add [nombre-de-los-archivos]
git commit -m "release-v1_1"
git checkout dev
git merge release-v1_1
git push

Y de ahí, tras hacer nuevos tests, a la rama principal:

git add [nombre-de-los-archivos]
git commit -m "release-v1_1"
git checkout master
git pull
git merge dev
git push
git checkout dev
git merge master

Al igual que haces con las ramas hotfix, cuando despliegues tu código en producción y compruebes que todo funciona correctamente, solo te quedará eliminar la rama release-v1_1. Para ello, usa este comando, desde tu rama dev:

git branch -D release-v1_1

Conclusiones

Como has podido ver, la metodología Git Flow te permite dividir tu proyecto en varias ramas de desarrollo dedicadas a tareas muy específicas de tu proyecto.

A lo largo de este artículo, has podido ver:

  • Qué es la metodología Git Flow
  • Tipos de ramas con las que se trabaja
    • Principal (master).
    • Desarrollo (dev).
    • Características (feature).
    • Corrección de errores (hotfix).
    • Versión y lanzamiento (release).

Es cierto, que esta es una adaptación de la metodología real, en la que se utilizan algunos tipos de ramas más, como por ejemplo, la de correción de errores antes de la salida a producción (bugfix). También utiliza una variación de los comandos básicos de Git. Por aquí te dejo un enlace al artículo donde el propio inventor de Git Flow te explica la metodología, tal y como él la diseñó, por si quieres echarle un vistazo y ampliar la información.

Ahh, antes de acabar, se me olvidaba decirte que en caso de que trabajes en equipo, en vez de ejecutar todas esas líneas de Git que hemos visto, lo que deberás hacer es solicitar una pull request al responsable del repositorio y, por tanto, del lanzamiento a producción. en este caso, será él quién ejecute los comandos correspondientes.

Por último, recordarte que para cualquier ayuda que puedas necesitar, aquí me tienes. Tan solo tienes que dejarme un comentario en el artículo o mandarme un correillo a través del formulario de contacto.

La imagen destacada ha sido obtenida del artículo A successful Git branching model de Vincent Driessen