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:

• Serie de artículos sobre git-flow en aprendegit.com
• Taller de git-flow en la Drupalcamp de 2013

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.

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.

• 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]».

Al 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»

En 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»

Presioná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.

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.

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.

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!

Durante el desayuno, compartí mesa, entre otros, con  Thomas Ferris Nicolaisen, 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é.

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!

Coincidiendo con el curso de git que impartimos en Badajoz, dimos una presentación de 40 minutos de introducción a git. La charla fue grabada y la podéis ver en youtube.

Ese mismo día, Álvaro de la Mata compartió con todos nosotros cómo cambiaron la forma de trabajo de toda la empresa aplicando metodologías ágiles en una charla que no tiene desperdicio. Aunque no se habla de git explícitamente, git y agilismo van bastante de la mano así que aquí os dejo el enlace.

Una presentación de una hora en la que hablamos de las herramientas que nos da git para no tener que recurrir al famoso borrar-y-volver-a-clonar-repositorio para recuperar nuestro repo cuando nos equivocamos.

Durante la presentación hacemos varias demos:

• Cómo detener un merge que nos ha dado conflictos
• Cómo deshacer un merge una vez finalizado
• Cómo deshacer un rebase que hemos hecho al revés, sobreescribiendo la historia del repositorio
• Cómo usar git-bisect para encontrar un bug
• Cómo usar git-revert para solucionarlo

¡No está mal para una hora! Espero que os guste y os resulte útil.

Aprovechamos para recordaros que en Aprendegit estamos siempre dispuestos para dar charlas y presentaciones sobre nuestra herramienta favorita. Así que si quieres que vayamos a hablar de git a cualquier sitio, sólo tienes que proponernoslo

La charla, que está escrita en TeX, podéis encontrarla en github. Independientemente de los recuerdos que me trajo ver el código fuente (la tesis la escribí en LaTeX) el contenido de la misma no tiene desperdicio. Si os interesa el tema, aunque sea árido, y queréis profundizar en él os recomiendo que leáis el capítulo 9 del libro de Scott Chacon.

Durante la charla se habló bastante de las referencias. Cuando Jesús acabó su magistral intervención, comenté un pequeño truco que aprendí en twitter para poder descargarnos a nuestra máquina los pull requests que recibimos desde github. Llevaba tiempo queriendo sacar un rato para contarlo y Jesús me dio el empujón que me faltaba.

Accediendo a los pull requests

En este artículo usaremos como base el repositorio que utilizamos para la serie de artículos sobre pull requests.

Cuando un usuario hace un pull request desde su fork al repositorio original, github crea en el repositorio orignal una referencia a los commits cuya incorporación se ha solicitado. El repositorio original, el que recibe el pull request, guarda estas referencias en refs/pull/*/head. Recordad que las referencias en git no son más que ficheros que contienen hashes a objetos de git. Estos ficheros están en los servidores de github.

Para poder acceder a esas referencias, y por lo tanto a esos commits, lo único que hay que hacer es decirle a git que se descargue los ficheros con las referencias cuando ejecutamos el comando fetch. Para ello, abrimos el fichero .git/config de nuestro repositorio y modificamos la sección correspondiente al remoto «origin», añadiendo la línea en cursiva que os pongo a continuación:

[remote "origin"]
 url = https://github.com/aprendegit/fork
 fetch = +refs/heads/*:refs/remotes/origin/*
 fetch = +refs/pull/*/head:refs/remotes/origin/pr/*/head

Antes de ejecutar git-fetch, veamos cómo están las referencias remotas del repositorio en SourceTree:

Referencias remotas antes de importar los pull-requests

Hagamos un fetch:

$ git fetch
From https://github.com/aprendegit/fork
 * [new ref]         refs/pull/1/head -> origin/pr/1/head
 * [new ref]         refs/pull/2/head -> origin/pr/2/head
 * [new ref]         refs/pull/3/head -> origin/pr/3/head

¡Ahí las tenéis! Si actualizáis la pantalla de SourceTree:

El repositorio después de hacer fetch de los pull requests

En la captura podéis ver los dos pull requests que ha recibido el proyecto y cómo ha evolucionado cada uno de ellos.

¿Y esto para qué sirve? Pues para probar el código que estáis recibiendo antes de aceptar el pull request, por ejemplo.

Para terminar, quería dar las gracias de nuevo a Jesús por su charla, a Kaleidos por la iniciativa y a Bert Belder (piscisaureus) por colgar el gist con la información que ha dado pie a este artículo.