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.