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.

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!

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

Queremos dar las gracias en primer lugar a todos los que os habéis tomado el tiempo de rellenar el formulario. A partir de los siguientes posts enfocaremos el contenido a lo que nos habéis pedido.

Resultados: Git Workflows, CLI y git-config

Con respecto al contenido, lo que más interés ha suscitado es lo relacionado con Workflows de git, seguido de la línea de comandos y la configuración con git-config.

Resultados: 30% Workflows, 19% Configuración con git-config, 19% Línea de comandos, 11% Github, 11% Crear mi servidor git, 7% GUIs, 4% Bitbucket.

También nos habéis convencido de que empecemos a grabar vídeos, así que en las próximas semanas empezaremos a hacerlo:

Resultados: 40% Las dos cosas, 30% Ver un vídeo, 30% Leer un tutorial

Con respecto a vuestros conocimientos, poco más de la mitad (60%) trabajáis con vuestro repositorio remoto y sabéis hacer pull y push. Sin embargo, pocos sois los que habéis trabajado con repositorios remotos, muy necesarios para poder implementar workflows en equipos distribuidos:

Resultados: 60% Trabajo con mi repositorio haciendo pull y push, 20% ¡apenas se instalarlo!, 10% se crear ramas y hacer un merge, 10% Trabajo con múltiples repositorios remotos y hago pull request a diario.

Entre los que nos habéis respondido, hay un porcentaje importante que todavía no trabajáis con remotos (30%). ¡Eso hay que cambiarlo!.

Conclusión

Empezaremos a generar contenido tanto en formato tutorial y vídeo relacionado con trabajo con múltiples ramas, git workflows y configuración de git. ¡Sin olvidarnos por supuesto de aquellos que estáis empezando!

De nuevo muchas gracias por vuestra ayuda.

¡Te estamos escuchando! ¡aprovecha y pide, que es gratis!

¿Porqué carpetas vacías?

Hay muchas herramientas, aplicaciones y frameworks que requieren de la existencia de ciertas carpetas para funcionar. Un ejemplo: tanto Symfony como Ruby on Rails necesitan disponer de directorios en los que almacenar cachés y logs. El contenido de estas carpetas se ignora siempre del repositorio; son archivos locales que sólo tienen sentido en cada copia local ¿pará que queremos distribuir a nuestros compañeros de trabajo los archivos de log creados por nuestro portátil mientras estamos desarrollando la aplicación? Es un derroche inútil de recursos y una fuente de conflictos que nos quitará mucho tiempo y no nos aportará nada.

El problema que se deriva de esto es que si ignoramos toda la carpeta completa utilizando un patrón de este tipo:

#Ignorando cache y log
cache/
log/

cuando otra persona clone el repositorio esas carpetas no se crearán. A no ser que las cree manualmente, la aplicación no funcionará.

La solución es decirle a git que cree las carpetas cuando clone el repositorio y luego que ignore su contenido. ¿Cómo se hace? creamos un fichero vacío dentro de la carpeta, lo añadimos al repositorio y le decimos a git que ignore el resto de archivos que están dentro. Esto se puede hacer de dos maneras:

• A través de un fichero .gitkeep
• A través de un fichero .gitignore

.gitkeep

Lo primero que debemos tener claro es que el uso del fichero .gitkeep es un convenio. En ningún lugar de la documentación de git veréis que se haga referencia a este fichero. De hecho, si no os gusta el nombre nada os impide cambiarlo y usar cualquier otro.

Veamos cómo usar este fichero:

• Antes de añadir al fichero .gitignore el patrón que ignore la carpeta cache, creamos el fichero cache/.gitkeep, bien usando el comando touch o con nuestro editor de texto o entorno de desarrollo.

# touch cache/.gitkeep

• Una vez creado el fichero lo añadimos al repositorio y hacemos el commit:

# git add cache/.gitkeep 
# git commit -m'Añadiendo el fichero cache/.gitkeep

• Editamos el fichero .gitignore (o lo creamos si no existe) y añadimos el patrón para ignorar la carpeta cache:

# Ignorando los ficheros de la carpeta cache/
cache/

•  Hacemos commit del fichero .gitignore

Ya está, la próxima vez que alguien cree el repositorio, se creará el fichero cache/.gitkeep a la vez que se ignora cualquier otro fichero que esté en la carpeta cache/.

Esta técnica utiliza la siguiente característica de git: si un fichero ya está en el índice (es decir, git ya está haciendo seguimiento de las modificaciones de ese fichero) a pesar de que el .gitignore lo ignore, git lo seguirá monitorizando.

Utilizar un fichero .gitignore

El método anterior tiene una pega: tenemos patrones para ignorar ficheros que requieren que tengamos varias excepciones en el índice de git (cache/.gitkeep, log/.gitkeep, etc). No hay problema con ello, aunque si no os gusta podemos utilizar otra de las características de git para no tener excepciones en el índice: utilizar un fichero .gitignore dentro de la carpeta que queremos ignorar.

• Crear el fichero cache/.gitignore con los siguientes patrones

# Ignorar todos los ficheros...
*

# ...excepto el fichero .gitignore
!.gitignore

• Añadir el fichero cache/.gitignore al repositorio y hacer un commit

Si repetís esta operación con las carpetas cuyos ficheros queráis ignorar, no tendréis necesidad de andar incluyendo excepciones en el índice.

Cualquiera de los dos métodos nos permite tener carpetas «vacías» en el repositorio, aunque vacías, vacías del todo no lo están. ¿Qué método usáis vosotros normalmente? ¡Esperamos vuestros comentarios!

¡Happy gitting!