El pasado 24 de octubre estuve en el Super Happy Dev House, 2009 que se realizó en el CESUN de El Lago.

Además de estar presente para escuchar otras pláticas, yo me apunté a una para presentar sobre Git.

El objetivo de la plática era dar a conocer a Git como un sistema distribuído de control de versiones, y tratar de demostrar su funcionamiento con un ejemplo.

Si bien la parte de la plática salió bien y las primeras muestras en proyección funcionaron, la demostración en la maqueta no salió como esperaba.

Fuera de que lo que llevaba como servidor se puso a hacer un fsck a la hora de levantar el lab y que hubo que levantar una red alterna porque los peers no se veían entre ellos, lo que realmente mató la demostración fue que olvidé el asunto de los permisos. Al no tener los usuarios permisos para leer los repositorios unos de otros, la demostración se convirtió en un ejemplo de VCS centralizado.

Realicé varios clones, uno de otro y con otro usuario para cuidar los accesos a la laptop. Para cuando todos clonaron del repositorio compartido, estúpidamente perdí rastro del árbol de repositorios generados. Pero en fin, estaba logrando recuperar camino, cuando…

Debido a que todos clonaron de mi repositorio –que tenía una working copy, es decir, que no era un repositorio bare— cuando quisieron darle git push sólo Alex pudo enviar sus cambios y ocurrió lo que tenía que pasar:

1. Que a los demás les apareció un mensaje sobre las «refs» que rápidamente se resolvió con git pull
2. Una vez realizado el pull, git les comenzó a rechazar el push, debido a que mi copia local estaba «sucia», es decir, que no correspondía con la última versión del HEAD.

Esto lo he resuelto múltiples veces con git reset --hard pero por algún motivo que desconozco, nunca pensé en forzar mi copia local a la versión actual de HEAD. Y aún si lo hubiera hecho, era demasiado tema para una sola sesión explicar git reset.

Algunos tuvieron conflictos y no pudieron realizar el git pull necesario para preparar el git push. Yo me preguntaba por qué tenían conflictos, y entre las tantas cosas que estaba tratando de resolver simultáneamente, el laboratorio me rebasó.

Afortunadamente, la parte conceptual quedó cubierta, algunos lograron instalar Git y ejecutar algunos de sus comandos.

Yo siento que quedé debiendo, así que he preparado un ejemplo que podrán leer y seguir con toda calma.

Se trata de una serie de acciones realizadas con Git afectando cuatro repositorios para demostrar la naturaleza distribuída de este gran manejador de versiones.

Hagan clic en la imagen para entrar a una tabla con cuatro columnas. Cada columna pertenece a los comandos ejecutados en un repositorio. Verticalmente es una línea de tiempo.

Si ustedes siguen todo el laboratorio en orden, los repositorios les quedarán de la siguiente manera: