Usando Git con git-flow

Ayer tuvimos una nueva reunión del grupo de usuarios de git (la última de este 2014 que se acaba).

En esta ocasión Oscar Vítores compartió con nosotros su experiencia en el uso de git-flow. La presentación fue muy interesante ya que no sólo se limitó a exponer qué es y cómo funciona, sino que nos contó cómo la usa con su equipo, qué le sirvió y cuándo git-flow empezó a quedarse corto.

El meetup estuvo muy bien, con muchas preguntas y comentarios durante la exposición. Gracias a todos los que estuvisteis allí y a Oscar por venir a contarnoslo en persona.

Aquí tenéis la grabación que hicimos a través de hangout (y aquí las diapositivas):

Una agradecimiento desde la organización de los meetups al espacio de coworking Kunlabori por cedernos la sala, micro y conexión para reunirnos y hacer la grabación.

Otros enlaces:

git no borra nada… hasta que pasa el recolector de basura

La semana pasada (el 21 de julio para ser más concretos) tuvo lugar el tercer meetup del grupo de usuarios de git.

En esta reunión estuvimos hablando de una característica muy importante y poco conocida de git: git no borra commits. Cuando hacemos ciertas operaciones, como un commit –amend, rebase o resets, parece que los commits se modifican o desaparecen. Sin embargo, lo cierto es que git no los borra, ni los modifica: siempre crea commits nuevos a partir de los anteriores.

Y si no los borra ¿por qué no los veo? ¿dónde están los commits originales? ¿cómo los puedo recuperar? y por último ¿cómo los borro definitivamente si es lo que realmente quiero hacer?. A estas y otras preguntas dimos respuesta en esta reunión.

Nos veremos de nuevo ya en septiembre ¡que paséis todos un buen verano!

Parte I: git no borra nada…

En esta primera parte de la charla, vemos una característica muy poco conocida de git: git mantiene los commits que parece que se han borrado y aunque no los veamos, siguen estando en nuestro repositorio (en la carpeta .git).

Para mostrarlo, comenzamos viendo cómo la opción –amend del comando git-commit no «modifica» el último commit sino que crea uno nuevo. Después pasamos a demostrar este comportamiento «rompiendo» un repositorio: ejecutamos una serie de operaciones (rebases y resets) hasta «perder» casi todos los commits y posteriormente utilizamos SmartGit y el reflog para «ver» esos commits que parece que se han perdido y devolver el repositorio a su estado inicial.

 

Parte II: …hasta que pasa el recolector de basura

En esta segunda parte de la charla, vemos cuáles son las condiciones que se deben cumplir para que los commits desaparezcan de y se borren definitivamente del repositorio. Analizamos el comportamiento del comando git-gc, aprendemos a caducar entradas del reflog para poder «limpiar» y finalmente borramos los commits del disco duro.

Al final de la presentación, hablamos del comando git-fsck y mostramos cómo funciona y qué información nos puede dar.

Primera reunión del grupo de usuarios de git

Después de unos cuantos meses un poco «inactivos» hemos retomado la actividad con fuerza. Hace casi un mes (el 13 de mayo) abrimos el Grupo de usuarios de git en meetup.com contando con Israel Alcazar, uno de los pesos pesados de git,  como coorganizador. En este tiempo se han unido al grupo más de 150 personas y ayer tuvimos la primera reunión en el Hogar Extremeño de Madrid.

Es un sitio atípico, con mucha historia detrás. Situado en el número 59 de la Gran Vía, el Hogar Extremeño se diseñó sobre plano a la vez que se hizo el edificio a finales de los 50. Lo mejor de todo no es lo bien comunicado que está, es que tenemos una barra con cervezas en el mismo salón en el que hacemos las charlas.

Aparte de git, dedico una buena parte de mi tiempo (la mayoría) al proyecto extremadura.com. Dentro de este proyecto tenemos un «subproyecto» podemos decir que se llama «Extremadura en el mundo» y que tiene como objetivo poner en valor todo lo que tenga que ver con Extremadura fuera de Extremadura. Estamos convencidos de que tradición y tecnología no son incompatibles y la mejor forma de demostrarlo es tener un meetup de git en un lugar tradicionalmente considerado como «para jugar a las cartas y al dominó». Fue muy divertido ver las caras de la gente cuando entraban allí como despistadillos, menos mal que avisamos que era un sitio atípico.

Desde la organización, queremos agradecer de manera especial al Hogar Extremeño y a todas las personas que hicieron que ayer nos sintiésemos como en casa (o incluso mejor).

Y ya sin más, os dejo las grabaciones de las dos intervenciones de ayer. Nos vemos en la siguiente.


Añadiendo un remoto a un proyecto en XCode5

En uno de los comentarios de la al post sobre las novedades de XCode 5, nos comentaba un lector que estaba teniendo algún problema para añadir un repositorio remoto a un proyecto en XCode 5. A continuación os indico cómo hacerlo usando la interfaz gráfica. Para ello, necesitamos lo siguiente:

  • Un proyecto XCode 5 que ya está bajo git.
  • La URL de un repositorio remoto, ya sea en BItbucket, Github, gitolite o el que sea en vuestro caso

Añadiendo un repositorio remoto git en Xcode 5

Desplegamos el menú «Source Control» dentro de XCode en nuestro proyecto. Dentro de este menú, en la sección «Working Copies», seleccionáis la única que inicialmente tendréis y que contiene el nombre del proyecto y la rama (normalmente master). En el submenú que se despliega, debéis seleccionar la última opción, que se llama «Configure [nombre del proyecto]».

Menú "Source Control" desplegadoAl hacer esto, nos aparecerá una ventana emergente con tres pestañas. Seleccionamos la pestaña «remotes» que mostrará un listado vacío. En la parte inferior derecha, hacemos clic sobre el icono «+» y se desplegará un menú con dos opciones:

  • Add remote
  • Create new remote

Seleccionamos la primera opción: «Add remote»

menú re repositorios remotosEn la siguiente ventana emergente que nos aparecerá, añadimos el nombre del repositorio remoto en el campo «Name» y la URL del repositorio en el campo «Address»

Selección de nombre del remoto y URLPresionáis en «Add Remote» y listo, ya tenéis el repositorio remoto configurado.

Para terminar, desplegáis el menú «Source Control», y seleccionáis push. En la ventana emergente seleccionáis el repositorio remoto que acabáis de crear, pulsáis el botón «Push» y ya tenéis el repositorio en vuestro remoto.

«Create New Remote»

En el menú de creación del repositorio remoto, hay una opción adicional «Create new remote» que está relacionada con las nuevas funcionalidades que nos traerá Mavericks y de la que hablaremos en un futuro.

Repaso rápido a las novedades de git en XCode 5

Hace ya una semana que la nueva versión de XCode, la versión 5, está disponible públicamente en la Mac App Store. En la presentación de la NSSpain de Logroño la semana pasada comenté que el soporte para git dentro de XCode ha mejorado en esta nueva versión aunque no pude entrar en detalles (cosas del NDA). Voy a empezar a destripar cuáles son las novedades que tenemos a nuestra disposición.

La cosa ha mejorado pero…

La verdad es que no es para echar cohetes. El cliente git sigue estando a años luz de otros IDEs que lo tienen integrado como Eclipse, Netbeams o los productos de jetbrains. Y si lo comparamos con SourceTree, Git Tower o Smart Git te das cuenta de que los ingenieros de Apple todavía tienen mucho trabajo por hacer.

Ahora bien, con las novedades que hay disponibles lo cierto es que hay algunas tareas más o menos recurrentes que ahora sí podemos hacer desde XCode, ahorrándonos unos cuantos cambios de pantalla al día.

Hacer commits desde XCode

Esta es una opción que ya estaba disponible en las versiones anteriores. Basta pulsar CMD-ALT-C para que se abra la interfaz, escribamos el mensaje y hagamos el commit. Esta pantalla no ha cambiado prácticamente nada con respecto a la versión 4.

Operaciones más habituales

Una de las características que tiene que tener cualquier SCM es la de «desaparecer», es decir, no darte cuenta de que lo estás usando. Las operaciones que hagas con él deben de ser rápidas y ágiles. Pues bien, XCode 4 estaba diseñado justo para lo contrario: para crear una rama era necesario abrir el organizador. El proceso era lento y suponía tener que cambiar de ventana, buscar un botón por ahí escondido, crear la rama, cambiarnos a ella y volver a la ventana del proyecto.

Aquí hay una sustancial mejoría. Ahora disponemos de un menú en la parte superior desde el que podemos hacer las operaciones más comunes: crear ramas, cambiarnos de rama, hacer push y hacer pull, deshacer cambios, resolver conflictos e incluso gestionar los remotos.Nuevo menú SCM en XCode5

Estas son las tareas más comunes así que cuando estamos trabajando nosotros solos o tenemos un flujo de trabajo muy simple, este menú nos puede ahorrar el tener que estar cambiando de aplicación para hacer cosas sencillas.

Gestión de repositorios remotos

La gestión de repositorios remotos del proyecto es ahora mucho más cómoda. En las pruebas que he realizado, he podido añadir el repositorio remoto de bitbucket y ha cogido mi clave SSH sin tener que hacer nada. En cuestión de un minuto tenía el remoto configurado y haciendo push/pull. En una entrada posterior veremos cómo hacerlo.

Mejoras sustanciales en la estructura de los ficheros XML

Esta es posiblemente la parte que más expectación ha despertado en los últimos meses desde que las versiones para desarrolladores han estado disponibles: ¡ahora se pueden hacer merges de los Story Boards!

Las mejoras más evidentes son:

  • Si ahora abres el story board o el fichero xib y no tocas nada, el fichero no aparece como modificado (lo que significa que no da conflictos).
  • Por otro lado, el formado de los ficheros ha cambiado y el XML, aunque sigue teniendo su miga, es más legible.
  • Este formato permite resolver conflictos en los XIB/Story Boards con mucha más facilidad, incluso de forma automática en algunos casos. En una primera prueba muy sencilla en la que creé dos botones en el mismo lugar en dos ramas diferentes dentro de un fichero .xib, pude resolver el conflicto muy fácilmente copiando un trozo del XML.

Aunque hay mejoras en este sentido, yo sigo siendo muy escéptico  En una prueba más elaborada en la que modifiqué un story board en dos ramas diferentes, la resolución del conflicto no era ya tan evidente y el XML no estaba tan claro. Me imagino que con un poco de práctica y experiencia será más fácil resolver los conflictos. Os iré contando cómo evoluciono según vaya usando más la herramienta.

¡El commit inicial incluye la configuración del IDE (xcuserdata)!

En XCode 4, cuando creabas un proyecto, había algunos ficheros que XCode no añadía al repositorio, en particular las carpetas xcuserdata. Pues bien, eso ya no es así y cuando creas un proyecto y marcas la casilla para que se cree el repositorio, XCode añade al repositorio todos los ficheros, incluido las carpetas xcuserdata.

A mi personalmente no me gusta tener esta información en el repositorio. Es cierto que existen algunos casos en los que puede ser útil: si queréis que todo el mundo comparta la configuración del IDE o para compartir breakpoints entre los miembros de un equipo. Mi experiencia es que en general, suele ser una fuente de conflictos que me quitan mucho tiempo y por eso ignoro estas carpetas en el .gitignore.

La que se lleva la palma…

La funcionalidad que más me gusta de todas las novedades que incluye XCode 5 en cuanto a la gestión de código fuente se refiere es…¡¡Poder desactivarla!!

Si abris las preferencias y vais a «Source Control», podéis desactivar el soporte SCM. Si lo hacéis, lo único que ocurre es que XCode ignora el repositorio git del proyecto, las opciones del menú «Source Control» aparecen desactivadas y el soporte para git deja de funcionar. El repositorio git queda intacto, así que podéis seguir usando la línea de comandos o vuestro cliente favorito para seguir gestionando el código fuente fuera de XCode.

Si después queréis activarlo, deshacéis los pasos y listo; eso sí, tuve que cerrar el proyecto y volverlo a abrir para que la interfaz volviera a mostrar los ficheros modificados y añadidos.

Voila_Capture289

Lo que sigo echando en falta

Aunque la cosa ha mejorado mucho, todavía echo en falta algunas cosas:

  • No entiendo la obsesión por ocultar el grafo. El grafo es ese típico dibujito lleno de pelotas, líneas y etiquetas que al principio no se entiende bien. Una vez sabes cómo funciona, cuesta trabajar en un repositorio sin él y en XCode no está.
  • Stashing
  • Rebasing
  • Poder hacer commits de parte de un fichero (interactive staging)
  • Más documentación acerca del formato XML de los xib y story boards (si alguien sabe dónde está que por favor nos lo diga). Eso nos permitiría resolver los conflictos más fácilmente.
  • Poder trabajar con flujos de trabajo un poco más elaborados. Si habéis trabajado o estáis trabajando con git-flow, vais a necesitar línea de comandos o Sourcetree necesariamente.

Conclusión

Si no te quieres complicar y el uso que haces de git se limita a hacer commits, push y pull, crear ramas y hacer merge, estás de enhorabuena: estas operaciones puedes hacerlas ya de manera rápida y efectiva en la nueva interfaz.

Ahora bien, si os soy sincero, la mayoría del tiempo sigo teniendo desactivado el soporte git y usando SourceTree y la línea de comandos, como hacía antes. El motivo principal: en cuanto quieres hacer cosas «normales» como un rebase, se te queda corto.

Por último, aunque el formato del fichero hace más sencillo el merging de ramas, sigo siendo escéptico en cuanto al uso de Story Boards. Sólo espero que esto no desemboque en Apple eliminando el soporte para ficheros xib en XCode ¡me tocará hacerlo todo por código!

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: hack day y como no, cerveza

Hace un par de días os escribía un resumen del Git Merge User Day. Aquí os dejo mis impresiones sobre el Hack Day.

Durante el desayuno, compartí mesa, entre otros, con  , que produce el podcast gitminutes.com. Su entusiasmo por lo que hace y cómo lo cuenta es especialmente motivador y me ha dado un par de buenos consejos para el blog que confío en poner en práctica en breve. Estaba, además, muy interesado en cómo está funcionando tanto este blog como los cursos de git así que estuvimos compartiendo datos de Google Analytics e intercambiando experiencias.

Compartiendo la mesa estaba con nosotros Scott Chacon, que nos estuvo contando cómo utilizan en github algunas de las herramientas para trabajar colaborativamente. Me quedé con dos ejemplos sobre cómo utilizan campfire:

  • Cuando se nombra a una persona en una sala, esta recibe un aviso y puede eventualmente unirse o responder offline si la sala ya está cerrada cuando se intenta conectar.
  • Meten las conversaciones de campfire en Elastic Search y luego utilizan el motor para buscar las conversaciones. Antes de esta combinación, aparentemente se perdía mucha información que luego no podía encontrarse de nuevo.

Curioso ¿verdad? Con estas «simples» modificaciones el ratio de participación en las conversaciones se disparó, así como la utilidad de la herramienta. También interesante cómo han ido evolucionando del «stupid drinking» al «we still drink a lot» con un, digamos, consumo responsable. Scott comentó durante el desayuno dos comandos que no conocía: git-fast-import y git-fast-export. Bastante útiles para mover commits de un sitio a otro sin hacer rebase (básicamente es copiar commits).

Después del desayuno empezamos a trabajar. Yo decidí hablar un poco más con Thomas, que me entrevistó para su podcast. Cuando terminé estuve charlando con algunas de las personas que hablaron el día anterior y aproveché una buena parte de la mañana para organizar las notas y avanzar lo máximo posible en los posts.

Después de comer empecé un pequeño proyecto en ruby que, utilizando rugged, me permite generar repositorios con commits y ramas predeterminadas. Situación muy habitual: te preguntan algo sobre un rebase y para responder necesitas un repositorio con dos ramas y varios commits en cada una de ellas. Antes empleaba unos 2-3 minutos en crear los commits y las ramas. Con esta herramienta puedo hacerlo en segundos. Está bastante verde, cuando la tenga un poco más pulida la liberaré. La verdad es que para dos horas que le dediqué al tema no está nada mal. Lo bueno de este tipo de eventos es tener a mano a la persona que te puede sacar del atolladero. En mi caso fue Carlos Martín Nieto, que me ayudó a desatascarme cuando no veía por dónde seguir.

Por la noche estuvimos en el Golgatha Biergarten. El nombre prometía y el DrinkUp desde luego no defraudó: para alguien que no le gusta la cerveza, beberse un litro y medio en una noche es todo un logro. Lo acompañé de un par de salchichas o tres (ya no me cuerdo). La verdad es que con un par de cervezas de ese tamaño en el cuerpo es más fácil romper el hielo así que seguimos hablando un poco de git, arreglando los problemas de España y comentando la cantidad de Españoles que había últimamente en Berlín. Como dijo Sergio: es la venganza por la «ocupación» Alemana de Mallorca.

Os animo a que asistáis a este tipo de eventos, y si es fuera de España mejor. Se aprende mucho compartiendo con gente de otros países. Hacía casi un año que no salía fuera y lo echaba de menos. El próximo viaje es el iOS Dev UK. Ya os contaré.

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

Todo listo para el git-merge 2013 de Berlín

Bueno, pues llegó el día… o casi. Mañana a estas horas estaré ya en Berlín para asistir al git-merge que ha organizado Github.

La verdad es que esto de ir a congresos «de friquis» me encanta, así que estoy como un niño la noche antes de que lleguen los reyes magos.

El programa promete… porque no hay programa así que el evento que va a ser bastante abierto. El primer día, el jueves, está reservado para los «contributors». El segundo tendremos un formato un-conference / lightning talks y el sábado será el hack day. Y como no, el motivo real por el que todos vamos a Berlín, que es el cierre del evento el sábado por la noche en el Golgatha Biergarten ¡Github drinkup!

Contará con la presencia de Matthew McCullough, Vicent Marti o  Thomas Ferris Nicolaisen, director del podcast «Git Minutes«. Con muchas ganas de ponerle cara a personas que llevo tiempo siguiendo y que han cambiado nuestra forma de trabajar. A la vuelta os contaré qué tal ha ido el evento.

¡Hasta la semana que viene!