Archivo del Autor: alfonso

Cómo deshacer el último commit en git

Aquí os dejo una manera sencilla de dar marcha atrás si habéis hecho un commit y os habéis arrepentido de hacerlo. El motivo por el que queréis «borrarlo» puede ser múltiple: porque el trabajo no está terminado y queréis continuar trabajando, habéis introducido un bug sin daos cuenta o sencillamente os habéis equivocado y lo habéis hecho antes de tiempo.

Existen dos maneras de borrar ese commit:

  • Eliminando junto al commit las modificaciones que este contiene
  • Recuperándolas en el área de trabajo para seguir trabajando en ellas

En ambos casos, el comando que utilizaremos será «git reset».

Deshacer el commit perdiendo las modificaciones

Supongamos que tenemos nuestro repositorio en el siguiente estado:

Voila_Capture283y queremos deshacer el último commit. En este primer caso, queremos desechar los cambios introducidos en ese commit que contiene una serie de tests funcionales.

Para ello, ejecutamos el comando:

git reset --hard HEAD~1

Tras ejecutar el comando, el estado del repositorio es el siguiente:

Repositorio tras borrar el commit

Como podéis ver, el commit 600cc08 ha desaparecido que era lo que queríamos. Además, la rama activa se ha desplazado un commit hacia abajo y nuestro área de trabajo ha quedado en el estado del commit 6eb9f2d. Los tests funcionales que estaban en el commit se han perdido y tendríamos que recurrir al reflog para recuperarlos.

La sintaxis HEAD~1 del comando anterior la podríamos traducir como «El commit al que está apuntando la rama activa menos uno». Si hubiésemos ejecutado el comando:

git reset --hard HEAD~3

en lugar de acabar en el commit 6eb9f2d (uno por detrás) habríamos acabado en 63db9fa (tres por detrás).

Deshacer el commit manteniendo las modificaciones

Existe la posibilidad de eliminar el commit pero manteniendo las modificaciones que contiene ese commit en el área de trabajo. ¿Y por qué querríamos hacer esto? Por varios motivos, por ejemplo por que los tests funcionales del commit 600cc08 están incompletos, son incorrectos o he introducido algún bug en él.

Partiendo de nuevo del mismos estado inicial de antes:

Estado inicial del repositorio.ejecutaríamos el siguiente comando:

git reset HEAD~1

Tras lo cual, el estado del repositorio sería:

Voila_Capture285Si miráis el estado veréis los siguiente:

  • Al igual que en el caso anterior, el commit 600cc08 ha desaparecido
  • La rama activa (rest) ha pasado al apuntar al commit 6eb9f2d
  • A diferencia del  caso anterior, el área de trabajo contiene las modificaciones que estaban en el commit que acabamos de borrar.

Así que podemos seguir trabajando, corregir el bug o completar los tests que habíamos dejado incompletos y hacer un nuevo commit con los cambios completos. ¡Así de fácil!

Muy útil pero…

Muy importante tener en cuenta que estas dos operaciones sobreescriben la historia del repositorio ¡estamos borrando un commit!. Si estamos trabajando en local y no hemos hecho push a nuestro remoto no hay ningún problema. Si ha habéis hecho push de este commit tened en cuenta que vuestros compañeros lo seguirán viendo si alguna de sus ramas lo referencia.

Espero que os haya resultado útil.

 

 

6 motivos por los que git no es un sistema de backup

Esta es una frase que escucho muy a menudo:

 “Yo tengo backup de mi repositorio git en github”.

Siempre que la escucho acabo teniendo la misma conversación con la persona que la ha dicho. Intento hacerle ver porqué github, bitbucket o cualquier otro servicio de hosting de repositorios no son una copia de seguridad de tu repositorio y cómo en determinadas circunstancias (muy habituales cuando trabajas en equipo) puedes perder información por usarlos para lo que no son.

Esto desde el punto de vista práctico. Si escarbamos un poco, lo normal es que detrás de esta frase se esconda un uso no del todo correcto de git o un desconocimiento de ciertas funcionalidades de la herramienta que espero corregir con este artículo.

En adelante me referiré a tu cuenta de github, bitbucket o cualquier otro sistema de hosting de repositorios git como servidor git.

1- Git es algo más que hacer un commit al final de nuestra jornada

El flujo más básico de uso de git que me he encontrado es el siguiente:

  • Llego a trabajar por la mañana y trabajo
  • Antes de irme hago un commit
  • Después del commit hago un push

Así, tienes en tu servidor git la última versión del código fuente. Si respetas este flujo, efectivamente tienes una copia de la última versión de tu código fuente en tu servidor. Ahora bien, no tienes una copia de tu repositorio, porque el repositorio del servidor al que haces push y el de tu máquina local son diferentes. ¡Por eso haces push!

Este forma de trabajo viola varias de las buenas prácticas de git:

  • No estás haciendo commits atómicos, pequeños y muy a menudo. Lo que significa que no estás pensando en cómo gestionar tu código sino en guardar la última versión en un «cajón de sastre» que es tu servidor
  • No estás trabajando con ramas locales para desarrollar funcionalidad
  • Probablemente, no tienes definido ningún flujo de trabajo que te permita gestionar cambios de contexto a la hora de trabajar

2- No estás guardando una copia de tus ramas locales

Las ramas locales, son eso, ramas locales. Las usas para muchas cosas, entre ellas para hacer pruebas, hacer refactorings del código o desarrollar funcionalidades en paralelo. Al no hacer push, de estas ramas, no tienes copia de los commits en tu servidor git.

Sé lo que estás pensando, basta con hacer push de todas las ramas y ya está. Bien, eso es correcto si estás tu solo con tu repositorio. Ahora bien, si estás trabajando en equipo y todos vosotros compartís el mismo repositorio git, la cosa cambia ¿Te imaginas a 5 personas todas subiendo sus ramas de prueba al servidor git para tener copia de seguridad? El caos está garantizado si no se organiza todo muy, muy, muy bien.

3- No estás guardando una copia del reflog

El reflog es un fichero de log que está en la carpeta .git de tu repositorio local donde se guarda un log de todos los cambios de referencias que ocurren en tu repositorio. Cada vez que cambias de rama, haces un merge, un rebase, un pull o un cherry-pick (entre otros) se guarda en el reflog lo que ha pasado.

Este fichero es el que te permite dar marcha atrás cuando la lías parda. Échale un vistazo a este hangout para un ejemplo sobre cómo se usa.

Tu reflog no está en tu servidor git. El servidor git tiene su propio reflog que no tiene porqué coincidir con el tuyo. De nuevo, si estás tu solo y haces push de todas tus ramas, el reflog del servidor se parecerá mucho al tuyo. Eso sí, en caso de desastre, tendrás que entrar al servidor a verlo o copiartelo a tu máquina local… oh, vaya, espera, que estás trabajando con github / bitbucket y no te dejan entrar a sus servidores a descargarte el reflog, desde luego qué tíos perros ¿no?.

Si estás trabajando en equipo, el reflog del servidor tiene todas las modificaciones de referencias hechas por tí y el resto del equipo. ¡Intentar encontrar algo en ese reflog es garantía de diversión durante horas!

4- No tienes backup de los hooks de tu repositorio git

Dentro de la carpeta .git/hooks de tu repositorio puedes poner hooks. Estos hooks no son más que scripts que se ejecutan antes o después de los comandos git y que te permiten interceptar la ejecución para hacer «cosas». Por ejemplo, el ‘pre-commit’ te permite manipular dinámicamente el mensaje del commit que se genera por defecto.

Cualquier hook que hayas puesto en tu máquina local en la carpeta .git/hooks, no tiene copia de seguridad en tu servidor git.

5- No tienes backup de tu configuración local

Dentro de tu repositorio tienes un fichero con la configuración local de tu repositorio: .git/config. En este fichero puedes guardar varias cosas, entre ellas el nombre y correo electrónico del autor de los commits, alisas de comandos de esos molones que te has bajado de internet y, en general, opciones de configuración específicas de ese repositorio en esa máquina.

Este fichero tampoco se sube a tu servidor git, así que en caso de desastre, lo pierdes y tienes que volver a generar la configuración del repositorio.

6- git permite sobreescribir la historia de tu repositorio

Si trabajas con más gente, en tu repositorio no vas a estar hurgando solo tú. Tendrás código de otras personas, harás merges o pull requests. Hay alguien que puede estar tocando el repositorio detrás de tí así que entre el momento que ocurre el desastre y «recuperas» el repositorio haciendo un clon, muchas cosas pueden haber cambiado.

Ponte en esta situación: te vas de vacaciones mientras tus compañeros trabajan en el repositorio. A la vuelta tu disco duro ha muerto, o durante el viaje te roban el portátil, así que clonas de nuevo el repositorio y te pones a trabajar… Lo que vas a clonar no es lo que tenías antes de irte, el repositorio contendrá todos los cambios que tus compañeros han hecho en tu ausencia.

Me dirás: “tío, no tienes ni idea. Una vez clonado hago un reset al commit de antes de irme de vacaciones y ya está”… Y yo te digo ¿Y no sabes que tus compañeros del alma pueden haberse cargado esos commits con un rebase, por ejemplo?. Recuerda: git, a diferencia de mercurial, permite sobreescribir la historia del repositorio así que ¡¡nada te garantiza que cuando vuelvas de tus vacaciones los commits sigan ahí!!

Conclusión

Según la wikipedia:

a backup, or the process of backing up, refers to the copying and archiving of 
computer data so it may be used to restore the original after a data loss event.

Si pierdes tu disco duro, y recuperas un repositorio haciendo un nuevo clon, no estás recuperando el repositorio como lo tenías antes del desastre así que según esta definición, no es una copia de seguridad. Además ¿Tú crees que Linus Torvalds hizo git para esto? ¿Para hacer backup? ¡eso ya lo tenía con los ficheros tar con los que empezó! Si solo lo usas para hacer copias de respaldo te estás perdiendo muchas cosas.

Git no es un sistema de copia de seguridad de nuestro código. Ahora bien, si se dan estas condiciones:

  1. Estás trabajando tú solo
  2. Haces push de todos los commits al repositorio remoto
  3. Todas las ramas que creas son remotas
  4. Tienes un repositorio que llamas scripts_y_configuracion en el que guardas los hooks, alias, pro-tips y configuraciones personalizadas de tus repositorios.

y eres consciente de lo que estás haciendo, puedes utilizar github como un backup (parcial) de tu código fuente, no de tu repositorio.

De igual manera, si trabajas en equipo y cada integrante tiene su propio repositorio, cada uno de vosotros podría usar git de esta manera. Aunque es un flujo muy básico que sirve para empezar a trabajar, no lo recomiendo en casi ningún caso: en seguida se te queda corto.

En mi caso particular, TimeMachine me ha salvado ya en varias ocasiones de problemas, ahorrándome mucho tiempo y trabajo. Aquí tienes mi consejo: usa una herramienta de backups para hacer backups y una herramienta de gestión de código para gestionar código.

git-merge 2013: user day

 

Estamos en Berlín en pleno Git Merge Hack Day. Ayer fue el user day en git-merge 2013, la conferencia para usuarios de git que Github ha organizado en la capital alemana este fin de semana. 

git-merge 2013

A primera hora registro y café y un ratito de networking hasta que ha dado comienzo la conferencia. El formato ha sido abierto y muy, como no, colaborativo (muy github):

  • Lightning Talks hasta la hora de la comida
  • Tarde libre en formato “open space” en el que se proponían temas para hablar sobre ellos

Para los que no sepáis lo que son las Lightning Talks, podemos resumirlo en lo siguiente: “el que tenga algo que compartir que salga y lo haga”.

Y la verdad es que ha salido bastante gente a compartir herramientas, presentarse, sugerir temas de conversación para la tarde o contar el último proyecto en el que estaba trabajando:

  • El primero ha empezado con fuerza. Un plugin para integrar XCode con Github disponible vía “Alcatraz”. Podéis encontrarlo aquí: https://github.com/larsxschneider/ShowInGitHub. Está todavía en desarrollo aunque la verdad es que promete bastante.
  • Luego nos han presentado una iniciativa para hacer públicas las discusiones de los parlamentarios a medida que las leyes se van elaborando. ¿Os imagináis a nuestros queridos políticos haciendo un merge de la ley antipiratería y luego haciendo un pull request para incluir sus modificaciones y comentarlas con el resto de grupos? No, yo tampoco. Hay sitios en los que esto pasa. Esto es madurez democrática y lo demás son tonterías. Aquí tenéis el repositorio y el listado de leyes: https://github.com/Bundestag y http://bundestag.github.io/gesetze/ (en Alemán).
  • Dos de los desarrolladores de git-submodules han presentado rápidamente las novedades que están implementando (https://github.com/jlehmann/git-submod-enhancements/wiki).
  • Christian Couder nos ha contado lo potente que es git-bisect para localizar bugs (http://es.slideshare.net/ChristianCouder/enjoy-fighting-regressionswithgitbisect). Además, es muy fácil automatizar la búsqueda con un test y, una vez localizado, corregirlo y crear un commit con la solución y el script de testeo. En una encuesta / estudio realizado entre 40 desarrolladores se ha observado un 40% menos de bugs y hasta un 80% de reducción en el tiempo de localización y depuración del bug cuando se utiliza con TDD. Una herramienta para tener en cuenta. En una intervención posterior, una persona de Ericsson ha compartido con nosotros como utilizó git bisect para detectar y corregir un bug en perl.
  • Roberto Tyley nos ha presentado BFG-repo-cleaner, una herramienta escrita en Scala que multiplica por mucho la velocidad de git-filter-branch: http://rtyley.github.io/bfg-repo-cleaner/. En este enlace tenéis un vídeo que compara el rendimiento de un raspberry-pi usando su herramienta vs un MacBook Pro usando git-filter-branch… por supuesto gana la RaspberryPi.
  • Michael Haggerty ha presentado git-imerge, una herramienta para hacer merges incrementales entre ramas de larga duración (http://softwareswirl.blogspot.de/2013/05/git-incremental-merge.html, https://github.com/mhagger/git-imerge). Muchas vences me habréis oído decir “no dejes el merge para el final”, haz merge a menudo para resolver los conflictos poco a poco. Puesta esta herramienta facilita esta tarea. Está todavía en modo experimental, seguiremos su evolución con atención porque es realmente útil.
  • Jack Pearkes ha presentado get una herramienta escrita en Go y pensada para hacer fetch de una cuenta de github y todos sus repositorios. Siguiendo con el ejemplo que ha puesto Jack, antes de salir de casa con el portátil, me hago un fetch de todos los repositorios de mi cuenta y me voy al tren con todos actualizados.
  • Filip Noetzel ha hablado de dos proyectos bumpversion y geocommit. El primero sirve para actualizar todas las cadenas de versión de un programa, crear un commit y etiquetarlo. Está escrito en python y nos puede ahorrar trabajo a la hora de generar una nueva versión de nuestra aplicación. El segundo, geocommit, es un servicio que geolocaliza los commits y nos ayuda a ver de dónde vienen las contribuciones a un proyecto.
  • Una persona nos ha presentado gource. Digo una persona porque no me he quedado con su nombre y no era el que lo ha desarrollado. Es una aplicación que lee el repositorio y hace una animación de cómo evoluciona un repositorio. Muy chulo el resultado para repositorios grandes con muchos participantes. Después de esto las pantallas han estado mostrando la animación del repositorio de git el resto del día.
  • Se hicieron varias presentaciones sobre libgit2. En este momento es la niña bonita de Github ya que como nos contó Vicent Martí en la presentación (http://vimeo.com/64716825) les ha permitido resolver varios problemas de escalabilidad en el backend. Se trata de una implementación de git empaquetada en una librería en C de forma que puede utilizarse en cualquier aplicación. ¿Te imaginas poder hacer un commit desde una aplicación echa por tí en ruby o python? Pues esto es, entre otras cosas, lo que permite hacer libgit2. La librería está bastante madura y tiene bindings para muchos lenguajes (lo siento, parece que Java no es uno de ellos de momento).
  • Relacionado con libgit2, tuvimos dos presentaciones de personal de Microsoft en la que nos mostraron cómo instalar y usar el plugin de git en Visual Studio 2012 y cómo clonar un repositorio alojado en TFS usando git-tf. Parece que dentro de poco Visual Studio ya incluirá el soporte de git nativo y no será necesario instalar ningún plugin.
  • Mislav Marohnić nos presenta hub una herramienta escrita en ruby para trabajar con repositorios github desde la línea de comandos. Github la utiliza en sus cursos intermedios/avanzados.
  • Sergei nos presentó una herramienta para enseñar git bastante curiosa, muy parecida a http://pcottle.github.io/learnGitBranching/. Aunque el código no está en este momento abierto sí se puede usar en este enlace http://io.git-init.ru/git-trainer/
  • Matthew McCullough nos habló sobre los recursos que github ha puesto a disposición de la comunidad para aprender git: teach.github.com, learn.github.com y www.youtube.com/github.
  • Simon nos presentó subgit una herramienta que permite utilizar un repositorio tanto con clientes subversion como con clientes git. Si trabajas con los dos sistemas o te estás planteando una migración, esta puede ser una herramienta muy útil.
  • Jetbrains hos nizo una rápida exposición de algunas de las mejoras en las que están trabajando para el cliente git que incluyen en sus IDE. Me gustó mucho lo que ellos llaman “smart checkout” que básicamente es un stash-checkout-unstash, muy útil cuando has hecho varias modificaciones en el código en la rama que no era. También mostraron una nueva característica: cuando te rechazan un push porque tus referencias no están actualizadas, tienes que volver hacer un pull y luego volver a hacer el push. En las próximas versiones, Jetbrains lo hará por nosotros dándonos la opción la hacer el pull con un merge o con un rebase. Estos chicos siempre pensando en que trabajemos menos…(http://www.jetbrains.com/idea/webhelp/using-git-integration.html)
  • Nos enseñan otro proyecto muy curioso: emscripten. Se trata de un compilador LLVM-to-Javascript, es decir, coge LLVM Bitcode y lo transforma en javascript… ¿qué excusa tenéis ahora para no escribir javascript?
  • Sergio Gil, con el que tuve el placer de estar charlando un buen rato durante la tarde, nos presentó GHContributors (http://ghcontributors.herokuapp.com/) una web que nos muestra todas las contribuciones que un usuario ha hecho a github.
  • http://www.versioneye.com/ un servicio que monitoriza las librerías que utilizas en tu proyecto y te avisa cuando cambian de versión.
  • Para cerrar la sesión, Scott Chacon nos habló del portal git-scm.com/community. Como el mismo dijo, una página para usuarios de git, no para desarrolladores. Nos estuvo hablando del libro (http://www.github.com/progit/progit) y de los planes que tiene para la segunda edición, que quiere escribir contando con la colaboración más activa de usuarios y desarrolladores. También se habló de la traducción del libro, que os recuerdo se realiza a través de la comunidad, y nos habló de que en github se están planteando incluso la contratación de traductores profesionales para mejorar ese aspecto. Por supuesto no dio fechas ni plasmaron un compromiso formal sobre ello, lo plantearon como opción para ayudar a resolver el problema que se plantea con un tema tan complicado como es la traducción. En esta discusión, que continuó más tarde en el grupo de formación en git, contamos con la experiencia de Axel Hecht (Mozilla) y cómo gestionan ellos las traducciones de sus herramientas.
  • Para terminar las ligthning talks, Scott nos recordó, por si se nos había olvidado, que github es el servidor de repositorios subversion más grande del mundo. Basta con que hagáis un checkout de cualquier repositorio de git con vuestro cliente favorito de subversion:
svn checkout https://github.com/progit/progit

IMG_0490

Después de las charlas, se establecieron varios grupos en los que se habló de diferentes temas: formación, migración a git, traducción de material y recursos. Matthew McCullough y Brent Beer estuvieron hablando sobre cómo enseñan git y github en diferentes partes del mundo. Entre las 10 personas que estuvimos charlando e intercambiando experiencias, había dos corrientes: los que mostraban el grafo desde el primer momento y los que preferían esperar un poco antes de mostrar las famosas “pelotas con padres”. La conversación fue muy productiva con ideas y un notas para mejorar los cursos de git.

En paralelo a esta conversación sobre formación en git, tuvo lugar otra muy interesante sobre migración. Como por el momento no he desarrollado la capacidad de estar en dos sitios a la vez, Peter Jönsson (https://github.com/mindjiver) and Andrey Devyatkin (https://github.com/Andrey9kin) tuvieron la gentileza de volver a hablar conmigo sobre cómo hicieron en Ericsson una migración de Clear Case a git que afectó a mil personas. Lo primero que hicieron fue formar un equipo de 8 personas que durante los casi dos años que duró el proceso se dedicaron en exclusiva a ese proyecto. Dado que tenían un alto grado de personalización en la instalación que tenían de Clear Case, tuvieron que realizar varias herramientas a medida para implementar la funcionalidad que necesitaban. De echo, 4 de las personas del equipo eran programadores de backend y frontend dedicados a la aplicación que han desarrollado. Una de las necesidades que tenían era el almacenamiento de metadatos en los repositorios y me estuvieron comentando que de las tres opciones que tenían (mensaje del commit, git-notes y etiquetas) finalmente optaron por almacenarlos en el mensaje del commit y desarrollar un parser con expresiones regulares para extraer y buscar la información. Comentamos opciones como almacenarlos en una base de datos (SQL o NoSQL) aunque no era para ellos una opción por complicar la infraestructura más de lo necesario.

Si algo saco en claro de la experiencia tanto mía como de las conversaciones que tengo con cualquier persona que afronta una migración en git es que no es un proceso sencillo. Requiere planificación y una adecuada ejecución, y aunque lo que se gana es mucho, el proceso es doloroso y requiere compromiso de todo el equipo para poder llevarlo a cabo con éxito.

Como veis un día muy intenso y productivo. Veremos cómo se desarrolla el hack-day.

Más enlaces

git-merge-2013

git-flow: Resumen y conclusiones

A lo largo de las últimas semanas hemos escrito una serie de cinco artículos en los que hemos hablado sobre git-flow:

  • En la introducción, vimos por qué surge esta extensión de git, qué hace y qué tipo de flujos de trabajo nos permite implementar.
  • Después instalamos git-flow, creamos un repositorio e inicializamos la extensión en el mismo.
  • Creamos las ramas develop y master y empezamos a desarrollar las historias de usuario del sprint usando feature branches.
  • Cuando terminamos nuestro sprint, utilizamos un release branch para testar y ajustar nuestro código antes de pasarlo a producción.
  • Finalmente vimos cómo corregir bugs urgentes en producción mediante el uso de hotfix branches.

 Qué nos aporta git-flow

  • Un flujo de trabajo básico para organizar el repositorio y nuestro trabajo.
  • Un convenio de nombres para nuestras ramas que permite a todos los miembros del equipo saber qué es cada cosa.
  • Unas reglas comunes a la hora de mover la información de una rama a otra.
  • Un conjunto de comandos que nos ahorra tiempo.
  • ¡Sourcetree tiene soporte en la aplicación! Si has entendido cómo funciona, puedes investigar cómo usarlo en la interfaz gráfica. Tienes el botón en la barra de herramientas.

Botón de git-flow en sourcetree

A lo largo de la serie siempre hemos relacionado los comandos de git-flow con los comandos git que la extensión ejecuta por detrás. Aunque nos facilite el trabajo, el uso de git-flow no nos exime de entender cómo funcionan las ramas, saber utilizar merge y rebase o entender la diferencia entre un pull y un fetch. Es entendiendo estos conceptos como le sacarás rendimiento a esta y a cualquier otra extensión de git.

He utilizado este flujo de trabajo en proyectos en los que he trabajado solo y proyectos con equipos de entre 3 y 5 personas.  Mi experiencia es que esta forma de organizar el repositorio es un buen punto de partida para el desarrollo de procesos más complejos, especialmente si el equipo no tiene mucha experiencia en el uso de git.

Como dijimos en la introducción, estas no son reglas absolutas. Y aunque funcionan en un gran número de equipos, puede que en tu caso necesites adaptarlas a tu forma de trabajar. Confío en que después de haber leído los artículos de esta serie, estés en condiciones de hacerlo.

git-flow: hotfix branches

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:

Repositorio tras cerrar release/1.0

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:

Estado de la rama develop antes del aviso de bug

Estado de la rama develop antes del aviso de bug

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'
Creando la rama hotfix/bug14

Estado del repositorio tras crear la rama hotfix/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:

bug #14 corregido

Estado del repositorio después de haber localizado y corregido el bug.

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
Introducir mensaje para el merge commit con la rama master

Se abre el editor predeterminado para introducir el mensaje del merge commit

  • El segundo es el mensaje que git-flow pondrá a la etiqueta que va a crear para identificar esta versión (vbug14)
Introducir mensaje para la etiqueta

Mensaje para la etiqueta de versión

  • El tercero y último será el mensaje que git-flow pondrá en el merge commit resultado de incorporar la rama hotfix/bug14 en develop
Introducir mensaje para el merge commit con la rama develop

Se abre el editor predeterminado para introducir el mensaje del merge commit con la rama 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:

Salida de git-flow al cerrar un hotfix branch

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:

Repositorio tras cerrar hotfix/bug14

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.

git-flow: release branches

En la entrada anterior vimos cómo utilizamos la rama develop y las features branches para desarrollar la primera versión de la aplicación. En este entrega veremos cómo utilizar las release branches  para preparar la puesta en producción de nuestra aplicación.

¿Para qué necesitamos una release branch?

El objetivo de estas ramas es preparar nuestra aplicación para su puesta en producción. En algunos equipos, estas ramas son las que se vuelcan en los servidores de pre-producción para hacer el testing final: se corrigen bugs, se pule la interfaz, se ajusta la maquetación…se hace la puesta a punto final de la aplicación antes de liberar la versión definitiva. Vamos a crear una release branch para la versión 1.0. Utilizando la línea de comandos, ejecutamos

$ git flow release start 1.0

Switched to a new branch 'release/1.0'
Summary of actions:
- A new branch 'release/1.0' was created, based on 'develop'
- You are now on branch 'release/1.0'

Follow-up actions:

- Bump the version number now!
- Start committing last-minute fixes in preparing your release

- When done, run:

git flow release finish '1.0'

Tras ejecutar estos comandos el repositorio queda de la siguiente manera:

Creando la rama release/1.0

Una vez creada la rama, empezamos el proceso de corrección y depuración, que en el ejemplo que nos ocupa da como resultado varios commits a la rama release/1.0. Así queda el repositorio cuando hemos terminado de arreglar todos los bugs y estamos listos para que nuestro proyecto pase a producción:

Repositorio justo antes de subir a producción

Cerrando la rama release con git-flow

En este punto, nuestro código fuente está testado, todos los bugs corregidos (o eso pensamos) y todo está listo para entregar la versión 1.0. Para cerrar la rama, ejecutamos

$ git flow release finish 1.0

Cuando ejecutamos este comando git-flow nos va a pedir que introduzcamos tres mensajes:

  • El primero de ellos es el mensaje del merge commit resultado de incorporar los cambios de release/1.0 en master

Introducir mensaje para el merge commit

  • El segundo mensaje es el mensaje que git-flow pondrá a la etiqueta que va a crear para identificar esta versión

Introducir mensaje para la etiqueta

  • El tercero y último será el mensaje que git-flow pondrá en el merge commit resultado de incorporar la rama release/1.0 en develop

Introducir mensaje para el merge commit con la rama develop

Cuando el comando termina, se nos muestra un resumen de todas las acciones que han tenido lugar:

Salida de git-flow al cerrar un release branchEn rojo hemos indicado las acciones que git-flow ha ido ejecutando y que pueden resumirse en los siguientes comandos:

git checkout master
git merge release/1.0 --no-ff
git tag v1.0
git checkout develop
git merge release/1.0 --no-ff
git branch -d release/1.0

El repositorio queda de la siguiente manera:

Repositorio tras cerrar release/1.0

Despliegue en producción

Dado que en este ejemplo estamos trabajando con una web HTML, el despliegue en producción es muy sencillo:

  • Sincronizamos las rama master con git push
git checkout master
git push
  • En el servidor en producción ejecutamos
git checkout master
git pull

Variaciones de este flujo

Cuando estamos trabajando en la rama release, puede darse el caso de que algunos bugs sean más complicados de resolver de lo esperado. Si eso ocurre, siempre podemos crear una rama dentro de release para corregir ese bug y, una vez terminado, incorporar los cambios a la rama release.

Conclusión

En esta entrega hemos visto cómo git-flow nos ayuda a gestionar la liberación de nuevas versiones de nuestro código fuente. Creando una rama específica para la puesta a punto de la versión, conseguimos que mientras una parte del equipo está trabajando release/1.0, otra parte puede avanzar en nuevas funcionalidades usando feature branches en la rama develop.

Lo que se debe evitar es utilizar la rama release para desarrollar nuevas funcionalidades. Si esto ocurre quiere decir que hemos pasado el código a pre-producción demasiado pronto.

En la siguiente entrega veremos cómo prepara hotfixes para nuestro código en producción.

git-flow: la rama develop y uso de feature branches

Seguimos con la serie de artículos sobre git-flow. Después de ver cómo pueden ayudarnos estas extensiones de git e instalarlas, vamos a empezar el desarrollo de nuestro proyecto utilizando git-flow.

Trabajaremos con una sencilla página HTML como ejemplo. No queremos complicar la explicación ni distraernos con el código fuente; el objetivo es entender el flujo que vamos a implementar con git.

Git-flow y metodologías ágiles

Los próximos artículos vamos a escribirlos en el contexto de las metodologías ágiles. Hablaremos de iteraciones, reuniones de planificación, reuniones diarias del equipo… El objetivo es poner git-flow en contexto y ver cómo nos puede ayudar.

Supongamos que ya hemos pasado por la reunión de planificación y hemos acordado en el equipo qué historias de usuario vamos a implementar en la primera iteración.

Las historias de usuario del primer sprint son las siguientes:

  • H-1: La web dispondrá de una home con un menú de acceso al resto de páginas
  • H-2: La página de inicio dispondrá de un hero con un texto y un botón de enlace al último artículo

Implementaremos la primera de las historias de forma manual y la segunda con git-flow. De esta forma entenderemos bien qué es lo que estas extensiones hacen por debajo.

Antes de empezar: git-flow-init

Dado que se trata de un proyecto nuevo, lo primero que haremos antes de empezar el desarrollo es, como no, crear el repositorio y prepararlo para usar git-flow. Para ello seguimos los siguientes pasos:

$ mkdir nuestro-proyecto
$ cd nuestro-proyecto
$ git init
$ git-flow init

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v

Al ejecutar el último comando, entramos en un menú interactivo que nos va preguntando las opciones que aparecen arriba:

  • Al inicializar git-flow, nos pregunta el nombre de la rama de producción y de la rama de desarrollo (master y develop respectivamente). Seleccionamos los nombres por defecto.
  • Después nos preguntará los prefijos que asignará a las ramas de tipo feature, release, hotfix y support. Volvemos a seleccionar los nombres por defecto.
  • Por último, nos pregunta el prefijo que queramos utilizar para etiquetar las versiones.

Si no os gustan los prefijos que usa git-flow por defecto, podéis utilizar otros. En un artículo posterior veremos como cambiar a posteriori estos nombres.

¿Y en qué estado queda nuestro repositorio después de hacer esto? Aquí tenéis una captura de SourceTree:

Estado del repositorio tras ejecutar git-flow

Estado del repositorio tras ejecutar git-flow

Vemos el commit inicial así como las ramas master y develop. Desde la línea de comandos, el repositorio tiene este aspecto:

$git branch -av
* develop 87ee184 Initial commit
  master  87ee184 Initial commit

Desarrollando H-1: gestionando las ramas manualmente

En el proyecto, en una de las reuniones diarias, se decide que vamos a usar bootstrap para maquetar la web, así que en la primera historia descargaremos bootstrap, lo incluiremos en la carpeta vendor y crearemos la página de inicio (nota para los usuarios más avanzados: somos conscientes de que hay mejores maneras de añadir bootstrap al proyecto como por ejemplo usar submódulos. Usamos este enfoque más simple porque no queremos distraernos con detalles ajenos al objetivo de esta serie que es entender git-flow).

Dado que se trata de un desarrollo planificado que formará parte de un futuro release (la versión 0.1) usaremos una feature branch.

Recordamos: las feature branches nacen de la rama develop y se incorporan a esa misma rama. Así que creamos una nueva rama a partir de develop que llamamos feature-H-1:

$ git checkout -b feature-H-1 develop
$ git branch -av
  develop     87ee184 Initial commit
* feature-H-1 87ee184 Initial commit
  master      87ee184 Initial commit

Una vez creada la rama feature-H-1, hacemos la siguiente serie de commits:

  • Añadimos bootstrap al proyecto
  • Creamos la página de inicio
  • Ponemos el menú

Cuando terminamos el desarrollo de la historia H-1, este es el estado de nuestro repositorio:

Terminado el desarrollo de la historia H1

Así queda el repositorio cuando terminamos de hacer el desarrollo de la historia H-1 en la rama feature-H-1

Ya hemos terminado nuestra primera historia, así que ha llegado el momento de incorporar los cambios a la rama develop (recuerda, las feature branches se incorporan a la rama develop):

$ git checkout develop
$ git merge --no-ff feature-H-1

Si no sabes qué es la opción –no-ff y porqué la usamos, lee este artículo. Al ejecutar el comando se nos pide el mensaje para el merge commit:

Merge branch 'feature-H-1' into develop

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.

Cuando guardamos y cerramos, este es el estado del repositorio:

Repositorio después de incorporar la rama feature-H-1

Estado del repositorio después de incorporar la rama feature-H-1

Como la rama feature-H-1 ha quedado visibles en el repositorio con un merge commit, podemos borrarla:

$ git branch -d feature-H-1
Deleted branch feature-H-1 (was 765ce08).

Pues bien, ya hemos terminado nuestra primera historia, vamos a por la segunda.

Desarrollando H-2: gestionando las ramas con git-flow

Para hacer esta historia, necesitaremos crear una nueva feature branch que llamaremos feature-H-2. Esta vez usaremos git-flow:

$ git-flow feature start H-2
Switched to a new branch 'feature/H-2'

Summary of actions:
- A new branch 'feature/H-2' was created, based on 'develop'
- You are now on branch 'feature/H-2'

Now, start committing on your feature. When done, use:

     git flow feature finish H-2

Notar que no necesitamos poner el prefijo “feature” para crear la rama, git-flow lo hace por nosotros. El propio git-flow se encarga de activar la rama feature/H-2 y de decirnos qué tenemos que hacer cuando terminemos. El estado del repositorio después de ejecutar el comando es el siguiente:

Usando git-flow para crear feature/H-2

Estado del repositorio después de crear la rama feature/H-2 con gitflow

Con la rama creada, nos ponermos a trabajar. Implementamos el hero de la página de inicio y hacemos los commits correspondientes:

rama feature/H-2 antes de cerrarla

Estado de la rama feature/H-2 una vez terminado el desarrollo

Así vemos las ramas desde la línea de comandos:

$ git branch -av
  develop     b7bd517 Merge branch 'feature-H-1' into develop
* feature/H-2 4604003 Introduciendo el texto definitivo
  master      87ee184 Initial commit

Si en un momento dado queréis listar las ramas de tipo feature desde la línea de comandos, basta con ejecutar git flow feature:

$ git flow feature
* H-2

Esto mismo es aplicable para las ramas hotfix, release y support.

Continuamos con el desarrollo. Revisamos y testamos nuestro código y cuando vemos que hemos terminado, utilizamos git-flow para cerrar la rama:

$ git flow feature finish H-2
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
  | 7 +++++++
 1 file changed, 7 insertions(+)
Deleted branch feature/H-2 (was 4604003).

Summary of actions:
- The feature branch 'feature/H-2' was merged into 'develop'
- Feature branch 'feature/H-2' has been removed
- You are now on branch 'develop'

Es decir, hemos vuelto a la rama develop, se ha incorporado la rama feature/H-2 a develop y la feature branch se ha borrado. Después de ejecutar el comando, este es el resultado:

Estado del repositorio tras cerrar la feature branch

Estado del repositorio tras cerrar la feature branch

Si os fijáis, hemos hecho lo mismo ejecutando menos comandos.

En esta captura vemos cómo en este flujo de trabajo queda reflejado en la historia del repositorio de forma bastante limpia y clara, cuándo se empezó y finalizó el desarrollo de cada una de las feature branches.

Ahora toca prepararlo todo para hacer el release a producción, aunque eso lo haremos en la siguiente entrega.

Hemos subido este repositorio a nuestra cuenta de github. Podéis verlo en este enlace: https://github.com/aprendegit/articulo-sobre-gitflow

Organizando las ramas en carpetas

Si en el momento de crear una rama utilizas como nombre una ruta, como por ejemplo “mi-carpeta-de-ramas/nombre-de-rama”, verás que en la carpeta .git/refs/heads de tu repositorio se creará una subcarpeta “mi-carpeta-de-ramas”. Dentro de la misma verás el fichero “nombre-de-rama” con la referencia. Es decir, git convierte la cadena con formato de ruta que pasamos como argumento en una estructura real de carpetas.

Esta forma de crear ramas soporta subcarpetas, es decir, si creamos una rama que se llame carpeta1/carpeta2/mirama:

$ git checkout -b carpeta1/carpeta2/mirama

git creará el fichero .git/refs/heads/carpeta1/carpeta2/mirama con la referencia.

¿Y cómo muestra SourceTree las ramas creadas de esta manera?

Organizando las ramas en carpetas

Esta forma de clasificar las ramas en carpetas es especialmente útil cuando trabajamos con ramas para hacer hotfixes, corregir bugs o desarrollar funcionalidades organizadas en historias de usuario.

Desde la interfaz de línea de comandos, así es como veríamos las ramas:

$ git branch -av
   carpeta1/carpeta2/mirama 4604003 Introduciendo el texto definitivo
   develop                  b7bd517 Merge branch ‘feature-H-1’ into develop
*  feature/H-2              4604003 Introduciendo el text definitive
   master                   87ee184 Initial commit

Si quisiésemos ver sólo las ramas feature, podemos usar la opción –list:

$ git branch --list feature*
feature/H-2

Para borrar la rama, usamos el comando git-branch con la ruta completa a la rama:

$ git branch -D carpeta1/carpeta2/mirama

Un truco muy sencillo que nos ayuda a organizar las ramas un poco mejor, especialmente útil si estáis usando SourceTree.

Instalación de git-flow en linux, windows y mac

Continuamos con la serie de artículos sobre git-flow. En la entrega anterior conocimos a Vincent Driessen y su flujo de trabajo. Hoy vamos a ver cómo instalar las extensiones en nuestra máquina.

Instalación de git-flow

Mac

Si habéis instalado git a través de homebrew o macports, la instalación se muy sencilla:

$ brew install git-flow
$ port install git-flow

Si tienes problemas con XCode 4.2 y Macports 2.0.4, sigue las instrucciones que se dan en la página de git-flow. También es posible utilizar la instalación a través de wget usando el script de instalación de Rick Osborne:

wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash

Linux

git-flow tiene paquetes para distribuciones basadas en debian y Ubuntu. Utiliza el gestor de paquetes de tu distribución, busca el paquete e instálalo. En debian/Ubuntu, el paquete se llama git-flow, en fedora gitflow y en Archlinux gitflow-git.

Si tu distribución no tiene paquete disponible en los repositorios oficiales como ocurre con centos 5, la mejor manera de instalarlo es utilizar el script de instalación:

wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sudo bash

Windows

Las instalación es un poco más tediosa, aunque no es complicada. Seguiremos las instrucciones que se dan en la página de git-flow aunque con un poco más de detalle:

 util-linux-ng para windows

  • Descomprimimos los dos ficheros descargados: util-linux-ng-[version]-bin.zip y util-linux-ng-[version]-dep.bin
  • Dentro de la carpeta “util-linux-ng-[version]-bin”, copiamos el fichero bin/getopt.exe a la carpeta C:\Program Files\Git\bin
  • Dentro de la carpeta “util-linux-ng-[version]-dep”, copiamos  el fichero bin/libintl3.dll a la carpeta C:\Program Files\Git\bin
  • Nota: en mi caso, tuve que hacer esto desde la línea de comandos lanzando un terminal de git bash como administrador de la máquina

descomprimiendo getopt.exe y libintl2.dll

  • Una vez copiados los ficheros, se clona el repositorio git://github.com/nvie/gitflow.git. Puedes clonarlo utilizando la línea de comandos o tu cliente gráfico favorito.
  • Por último, abrimos una terminal de windows dentro del repositorio que acabamos de clonar y ejecutamos el comando contrib/msysgit-install.cmd “C:\Program Files\Git” (sustituyendo la ruta si en tu máquina la tienes en una carpeta diferente). Nota: este terminar también tuve que lanzarla como usuario administrador, mi usuario de trabajo no tiene permiso en la carpeta C:\Program Files\Git.

msysgit-install.cmd

Listo, para confirmar que lo tenemos instalado, abrimos git bash, creamos una carpeta vacía y dentro inicializamos el repositorio con el siguiente comando:

 

$ git flow init

Si todo ha ido bien, esto es lo que deberíamos observar:

Comprobando la instalación

¿Qué es git-flow?

Empezamos una serie de artículos sobre git-flow, conjunto de extensiones de git que facilitan la gestión de ramas y flujos de trabajo.

Si quieres seguir esta serie, debes disponer de una máquina con git instalado:

  • Windows: msysgit que puedes descargar de este enlace
  • Mac: a través de homebrew o macports
  • Linux: a través del gestor de paquetes de tu distribución

Flujos de trabajo

Hace unos días participé en el Open Space de Calidad del Software organizado en Madrid este mes de febrero. En la reunión se abordaron varios temas que iban desde responder a preguntas como ¿qué se calidad del software? ¿cuánto cuestan los tests funcionales? o ¿cómo hacer testing de desarrollos para dispositivos móviles? pasando por otros tan exóticos como el Pirata Roberts, llegando incluso a plantearse hasta la eliminación de los responsables de calidad de la faz de la tierra.

En casi todas las conversaciones en las que tuve la oportunidad de participar había un denominador común: las ramas. Se hablaba de ramas para hacer hot-fixes urgentes, ramas para desarrollar nuevas versiones separadas de las ramas maestras donde está la versión en producción. Ramas para probar nuevas versiones, ramas y repositorios para trabajar con proveedores externos, ramas para hacer pruebas en pre-producción, ramas para que los departamentos de calidad hagan sus pruebas antes de liberar nuevas versiones. Con git podemos crear ramas “como churros” y ese fin de semana tuve la oportunidad de compartir con varios colegas de profesión cómo utilizar las ramas para hacer el bien. Sin embargo, esta facilidad para crear ramas también se puede utilizar para hacer el mal y sembrar el terror. Más de una vez he visto ramas creadas sin ningún criterio, sin ningún flujo de información detrás que las sustente. Esta situación suele llevar al repositorio al caos más absoluto.

Para no acabar en el caos, debemos establecer unas “reglas del juego” que todo el equipo debe respetar. Aunque a grandes rasgos casi todos los proyectos pueden utilizar unas reglas de base comunes, las reglas deben ser flexibles para adaptarse a los cambios que puedan surgir en el tablero de juego; al fin y al cabo, las necesidades y particularidades de cada equipo, empresa o proyecto no son las mismas.

¿Y cuáles son estas reglas base comunes? En enero de 2010 Vincent Driessen publicó en su blog un artículo en el que compartía con la comunidad un flujo de trabajo que a él le estaba funcionando: “A successful Git branching model”. Como él mismo cuenta en el artículo (te recomiendo encarecidamente que lo leas) Vincent propone una serie de “reglas” para organizar el trabajo del equipo.

Ramas master y develop

El trabajo se organiza en dos ramas principales:

  • Rama master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción
  • Rama develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto

Cada vez que se incorpora código a master, tenemos una nueva versión.

Además de estas dos ramas, Se proponen las siguientes ramas auxiliares:

  • Feature
  • Release
  • Hotfix

Cada tipo de rama, tiene sus propias reglas, que resumimos a continuación.

Feature or topic branches

feature branches

fuente: nvie http://nvie.com/posts/a-successful-git-branching-model/

  • Se originan a partir de la rama develop.
  • Se incorporan siempre a la rama develop.
  • Nombre: cualquiera que no sea master, develop, hotfix-* o release-*

Estas ramas se utilizan para desarrollar nuevas características de la aplicación que, una vez terminadas, se incorporan a la rama develop.

Release branches

  • Se originan a partir de la rama develop
  • Se incorporan a master y develop
  • Nombre: release-*

Estas ramas se utilizan para preparar el siguiente código en producción. En estas ramas se hacen los últimos ajustes y se corrigen los últimos bugs antes de pasar el código a producción incorporándolo a la rama master.

Hotfix brancheshotfix branches

  • Se origina a partir de la rama master
    fuente http://nvie.com/posts/a-successful-git-branching-model/
  • Se incorporan a la master y develop
  • Nombre: hotfix-*

Esas ramas se utilizan para corregir errores y bugs en el código en producción. Funcionan de forma parecida a las Releases Branches, siendo la principal diferencia que los hotfixes no se planifican.

¿Qué es git-flow?

Si queremos implementar este flujo de trabajo, cada vez que queramos hacer algo en el código, tendremos que crear la rama que corresponda, trabajar en el código, incorporar el código donde corresponda y cerrar la rama. A lo largo de nuestra jornada de trabajo necesitaremos ejecutar varias veces al día los comandos git, merge, push y pull así como hacer checkouts de diferentes ramas, borrarlas, etc. Git-flow son un conjunto de extensiones que nos ahorran bastante trabajo a la hora de ejecutar todos estos comandos, simplificando la gestión de las ramas de nuestro repositorio.

La flexibilidad de git…y el sentido común

Las «reglas» que Vincent plantea en su blog son un ejemplo de cómo git nos permite implementar un flujo de trabajo para nuestro equipo. Estas no son reglas absolutas, bien es cierto que pueden funcionar en un gran número de proyectos, aunque no siempre será así. Por ejemplo ¿qué pasa si tenemos que mantener dos o tres versiones diferentes de una misma aplicación? digamos que tenemos que mantener la versión 1.X, la 2.X y la 3.X. El tablero de juego es diferente así que necesitaremos ampliar y adaptar estas reglas para poder seguir jugando.

git es una herramienta que nos permite modificar estas reglas y, lo que es más importante, irlas cambiando y adaptando a medida que el proyecto avanza y el equipo madura. Una vez más, una buena dosis de sentido común será nuestra mejor aliada para responder las preguntas que nos surjan durante el camino.

Referencias: