Seguimos hablando de git-flow. En la entrada anterior vimos cómo utilizar un release branch para poner a punto nuestra aplicación antes de llevarla a producción. En esta última entrega de la serie veremos cómo utilizar git-flow para gestionar la resolución de bugs urgentes y, en general, cualquier tipo de modificación que requiera un rápido despliegue en producción.
¿Qué son las hotfix branches de git-flow?
Recordemos cómo había quedado nuestro repositorio tras la puesta en producción:
- La rama master, que actualmente contiene la versión 1.0, ya ha sido desplegada en producción
- La rama develop, que ya incorpora todos los cambios y ajustes que hicimos durante la puesta a punto de la versión 1.0, está lista para avanzar en el desarrollo de la versión 1.1
Recordemos cómo dejamos el repositorio en la entrega anterior:
Estamos listos para empezar un nuevo sprint. Tenemos una reunión de planificación, ponemos en el backlog las historias de usuario que vamos a desarrollar para la versión 1.1, y empezamos a trabajar.
A los pocos días, recibimos un aviso de nuestros compañeros del departamento de atención al cliente: ¡hay un bug de la aplicación en producción! Git-flow utiliza hotfix branches para implementar un flujo de trabajo que permite:
- Interrumpir el trabajo que estamos haciendo en la rama develop para la versión 1.1
- Resolver el bug
- Incorporar la corrección del bug en la rama master para desplegarlo en producción lo más rápido posible
- Incorporar la corrección del bug en la rama develop (si procede)
- Retomar el trabajo que estábamos haciendo en la rama develop
Para los que estáis familiarizados con la administración de sistemas, a mí cada vez que me pasa esto me siento como el kernel de Linux haciendo context switching. Cada vez que tenemos que dejar cambiar de rama tenemos que cambiar de contexto. Eso implica recordar qué estábamos haciendo, qué teníamos en la nueva rama y en qué estado estábamos. Sin una herramienta como git, que permite hacer este cambio de forma rápida y viendo la historia de las dos ramas, el tiempo necesario para hacer el cambio de contexto nos hace menos productivos. Las ramas hotfix nos ayudan a hacer estos cambios de contexto de forma más eficiente y a corregir el problema con el mínimo impacto sobre el resto del trabajo que estamos haciendo.
Creando la rama hotfix/bug-14
Como hemos comentado antes, supongamos que ya llevamos unos cuantos días trabajando en el sprint. Habremos creado una (o varias) feature branches y el estado de nuestro repositorio puede ser algo parecido a esto:
Nos encontramos trabajando en la historia de usuario H5 cuando recibimos la llamada de nuestros compañeros avisándonos del bug.
Lo primero que haremos será almacenar el trabajo que estamos haciendo y que vamos a tener que interrumpir porque tenemos que cambiar de contexto. El objetivo es guardar este trabajo a medias y recuperarlo cuando hayamos terminado de corregir el bug. Hay varias formas de hacer esto, nosotros lo guardaremos en el stash ya que prevemos que la corrección del bug no nos llevará mucho tiempo:
$ git stash save 'Antes de empezar a corregir el bug #14' Saved working directory and index state On feature/h5: Antes de empezar a corregir el bug #14 HEAD is now at f6609a9 Primera implementación de las páginas estáticas
Podemos ver el contenido del stash con el comando git stash list
$ git stash list stash@{0}: On feature/h5: Antes de empezar a corregir el bug #14
El objetivo de esta entrada no es hablar del stash, así que entraremos en detalle en otra ocasión. Si no sabes lo que es, puedes consultar este enlace. Seguimos.
Una vez tenemos nuestro trabajo almacenado y listo para cambiar de contexto, creamos la rama hotfix/bug14:
$ git flow hotfix start bug14 Switched to a new branch 'hotfix/bug14' Follow-up actions: - Bump the version number now! - Start committing your hot fixes - When done, run: git flow hotfix finish 'bug14'
Los comandos que git-flow ha ejecutado por nosotros son en este caso bastante sencillos:
$ git checkout master $ git checkout -b hotfix/bug14
Con la rama creada, empezamos a trabajar en la corrección del bug. Pasadas unas horas y unos cuantos commits después, tenemos el bug corregido y listo para subir a producción. Este es el estado del repositorio:
Cerrando la rama hotfix/bug14
Nos acercamos al final. Una vez corregido el bug, procedemos a cerrar la rama hotfix:
$ git flow hotfix finish bug14
Cuando ejecutamos este comando, git-flow nos pide que introduzcamos tres mensajes:
- El primero de ellos es el mensaje del merge commit resultado de incorporar los cambios de hotfix/bug14 en master
- El segundo es el mensaje que git-flow pondrá a la etiqueta que va a crear para identificar esta versión (vbug14)
- El tercero y último será el mensaje que git-flow pondrá en el merge commit resultado de incorporar la rama hotfix/bug14 en develop
Al igual que cuando cerramos la rama release/1.0, al finalizar la ejecución del comando se muestra un resumen de todas las acciones que han tenido lugar:
En rojo hemos indicado las acciones que git-flow ha ido ejecutando y que pueden resumirse en los siguientes comandos:
git checkout master git merge hotfix/bug14 --no-ff git tag vbug14 git checkout develop git merge hotfix/bug14 --no-ff git branch -d hotfix/bug14
El nombre que git-flow ha puesto a la etiqueta no es precisamente el más adecuado, así que borramos esa etiqueta y creamos una nueva que se llama v1.0.1. El repositorio queda de la siguiente manera:
Y ya está, casi hemos terminado… Sólo nos falta volver a cambiar de contexto y recuperar el repositorio como lo teníamos antes de empezar a corregir el bug.
Volviendo a la rama feature/h5
Este paso es el más sencillo, basta ejecutar el comando
$ git checkout feature/h5
Ahora bien: ¿cómo recuperamos ese trabajo a medias que habíamos tenido que interrumpir y que almacenamos en el stash?
$ git stash list stash@{0}: On feature/h5: Antes de empezar a corregir el bug #14 $ git stash pop stash@{0} Auto-merging
(Nota: dado que sólo tenemos una cosa guardada en el stash, podríamos ejecutar sencillamente git stash pop).
Y con esto hemos terminado, ya tenemos todo listo para seguir trabajando en la historia de usuario H5.
Conclusión
En esta entrega hemos visto cómo git-flow nos ayuda a gestionar la corrección de bugs del sistema en producción a través de hotfix branches. Creando una rama específica para corregir el bug, conseguimos que mientras una parte del equipo está trabajando en la rama develop, otra parte pueda corregir el bug. Si es una misma persona la que tiene que hacer este trabajo, la creación de estas ramas auxiliares facilita el cambio de contexto al desarrollador.
Este tipo de ramas no tienen mucho sentido en las ramas develop ya que la detección y corrección de bugs forma parte del proceso de desarrollo de nueva funcionalidad
En la siguiente entrega haremos un pequeño resumen de lo que hemos visto en esta serie de artículos y daremos por terminada la serie.
Pingback: git-flow: release branches | Aprende GIT
Tienes un pequeño bug en una linea de comandos 😉
$ bit checkout feature/h5
En el título: Volviendo a la rama feature/h5
Ante todo, felicidades, un gran blog que me marco como favorito 😉
Ya está corregido ¡¡Muchas gracias!!
Hola gracias a tus tutoriales he aprendido bastante sobre git y pues esto de gitflow lo estoy implementando en mis proyectos desde que lo vi en este sitio web. Pero todo el trabajo lo hago con SourceTree porque no estoy muy acostumbrado al trabajo con consolas, sin embargo en ciertas ocasiones al finalizar las ramas feature o hotfix me da error, no se si sea producido por mí o por alguna falla. Lo cierto es que cuando las hago por consola no da error. Mi pregunta para ti es la siguiente: Cuando dices
Cuando ejecutamos este comando, git-flow nos pide que introduzcamos tres mensajes:
A mi se me abre para colocar el primer mensaje, pero no se que tecla presionar para confirmar el mensaje y pasar al siguiente. He intentado varias cosas y no se como es. Yo no utilizo la consola de Windows sino GitBash, y pues nunca he podido confirmar los mensajes porque no se como y termino colocándolos mediante SourceTree. Si me puedes ayudar te lo agradezco ya que quiero trabajar mayormente con la consola.
Hola Eborio:
Perdona que haya tantísimo en responderte, se me ha colado el mensaje en SPAM y no lo he visto hasta ahora :-(.
No tienes que dar a ninguna tecla. Cuando te pide el mensaje, git-flow está ejecutando por detrás un comando git-commit. Como consecuencia, te abrirá un editor de texto (creo que en windows es vi, corrígeme si me equivoco) para que escribas el mensaje. Una vez lo tengas escrito, tan sólo tienes que guardar y cerrar el editor para pasar al siguiente (en vi: presionas «ESCAPE» para entrar en modo comandos y entonces pones «:wq»). Haces esto para cada mensaje y ya está.
¿Resuelve esto el problema?
Alfonso
Hola, creo que hay una errata en:
git merge hotfix/1.0 –no-ff
y debería ser
git merge hotfix/bug14 –no-ff
Gracias por el artículo.