¿Qué es gitflow?

Si llevas algún tiempo usando git como sistema de control de versiones es probable que hayas oído sobre o incluso estés usando la estrategia llamada "gitflow" acuñada en el 2010 por Vincent Driessen en su artículo A successful Git branching model

En este artículo tengo la intención de hacer un resumen/traducción de esta estrategia para poder compararla con otras que he ido descubriendo para tener una recopilación, ya que dependiendo del proyecto en el que trabajes, te interesará más una u otra. 

Nota: el autor en su artículo original da detalles sobre los comandos git a utilizar en cada caso que expone que yo he decidido omitir por brevedad

 

Gitflow

Para empezar, esta estrategia define un núcleo comprendido por dos ramas las cuales van a tener un tiempo de vida infintio:

  • master
  • develop

Donde master es la rama que refleja el estado actual en producción del proyecto y develop es la rama que almacena los últimos cambios desarrollados y que están preparados para pasar a producción en la siguiente release.

 

Ramas de apoyo

Al considerar master y develop ramas infintas, esta estrategia necesita de otras ramas para poder desarrollar nuevas funcionalidades en paralelo y poder hacer un seguimiento coherente. Estas ramas tendrán una vida finita y se dividen en:

  • ramas de funcionalidades
  • ramas de lanzamiento (release)
  • ramas de revisiones (hotfix)

Según el autor, cada una de las ramas presentadas tiene un propósito muy concreto y están ligadas a unas normas muy estrictas sobre desde donde se originan y donde pueden unirse.

 

Ramas de funcionalidades

  • Pueden bifurcarse desde develop
  • Tienen que unirse a develop
  • Se pueden nombrar de cualquier manera menos master, develop, release-* o hotfix-*

Estas son las ramas que nacen normalmente a causa de un ticket, o de una necesidad que hemos detectado, cada desarrollador crea sus propias ramas de funcionalidades cada vez que tiene que añadir código al proyecto. Estas ramas son desechables, cuando la funcionalidad quede terminada y aprobada se hará un "merge" a master y se eliminarán. Si usas Gitlab o Github, estas ramas son las que componen una merge request o pull request para poder revisar el código.

 

Ramas de lanzamiento

  • Pueden bifurcarse desde develop
  • Tienen que unirse a develop y a master
  • Se deben nombrar release-*

Estas ramas dan apoyo para la preparación de un nuevo lanzamiento a producción, el objetivo de su existencia es para poder preparar el merge a master y hacer adiciones o arreglos de última hora de manera que la rama develop quede libre para que los desarrolladores puedan continuar con el siguiente lanzamiento. 

Por ejemplo, si faltan tres dias para la entrega y el equipo ya la tiene lista y quiere empezar con la siguiente puede hacerlo sin problemas, eso sí a partir de ese momento si se tienen que hacer arreglos de bugs se deberán hacer sobre la rama de lanzamiento y no sobre develop.

Cuando la rama esta preparada para pasar a producción, primero debemos unirla a master creando un nuevo commit en el que crearemos una etiqueta (tag) con el nuevo número de versión para futuras referencias. Finalmente, tenemos que devolver la rama a develop para no perder las adiciones de última hora ni los arreglos de posibles fallos.

 

Ramas de revisiones

  • Pueden bifurcarse desde master
  • Tienen que unirse a develop y a master
  • Se deben nombrar hotfix-*

Estas ramas son parecidas a las ramas de lanzamiento en el sentido de que el motivo de su existencia es preparar el código para un lanzamiento a producción con la diferencia de que se crean de manera no planeada y con una necesidad inmediata al haber encontrado algún error en el código que ya esta en producción. 

Su bifurcación se debe hacer sobre la correspondiente etiqueta que esta en producción, dejando así libre la rama develop para que el resto del equipo pueda seguir trabajando, a parte, seguramente no nos interesa el código de la rama develop ya que puede no ser del todo estable o contener funcionalidades que no se esperan aún.

Al terminar de arreglar los errores, esta rama tiene que ser devuelta a master y unida a  develop para no perder el código en el siguiente lanzamiento con la excepción de que si en el momento en el que se quiere unir la rama a develop existe una nueva rama de lanzamiento aún sin unir a master, esta rama de revisión debe ser unida a la rama de lanzamiento en lugar de la rama develop, ya que así nos ahorramos trabajo y no tenemos que descartar la rama de lanzamiento para crear una de nueva con el arreglo.

 

Conclusión

No me aventuraré demasiado en sacar conclusiones ni dar mi opinión personal sobre esta estrategia ya que no la he usado aún, ni profesionalmente ni para mis trabajos personales. No obstante, parece ser muy rígida al tener que crear tantos tipos de ramas diferentes con sus respectivas normas, esto suele acarrerar una inversión de tiempo mayor al tener que mantener todas tus ramas y despliegues a producción en su orden correcto. Lo que si que me gusta es que permita que el desarrollo siga cuando tienes una entrega completa y el poder arreglar errores de producción sin terminar subiendo funcionalidades que aún no estan completas o que los usuarios no deberían ver, claro esta, este tipo de despliegues creo que son más idóneos para consultoras con entregas muy marcadas ya que entran en contraposición con la cultura o moda de hacer 100 despliegues al día adoptada por startups.

Próximamente publicaré otros artículos con más estrategias git para poder comparar los puntos fuertes y no tan fuertes entre unas y otras

 

 

¿Te ha gustado el artículo? ¿Quieres que te avise de mis próximas publicaciones?

¿Quieres seguir aprendiendo?

Destructuración de Objetos en JavaScript

¡Hola! Siguiendo la serie de videos explicando funcionalidades interesantes y aprender JavaScript moderno, hoy voy a explicar el destructuring. Hacer destructuring es simplemente dividir un objeto o colección en partes más simpl...

Seguir leyendo