Git prune

La salida de git log muestra las 2 confirmaciones y los mensajes de confirmación correspondientes sobre las ediciones realizadas en hello.txt. El siguiente paso es hacer que una de las confirmaciones sea inaccesible. Para ello, utilizaremos el comando git reset. Restablecemos el estado del repositorio a la primera confirmación (“added hello.txt”).

Si ahora utilizamos git log para examinar el estado del repositorio, podemos ver que solo tenemos una confirmación.

El repositorio de demostración ahora está en un estado que contiene una confirmación desasociada. La segunda confirmación que hicimos con el mensaje “added another line to hello.txt” ya no aparece en la salida de git log y ahora está desasociada. Puede parecer que hemos perdido o eliminado la confirmación, pero Git es muy estricto en cuanto a no eliminar el historial. Podemos confirmar que todavía está disponible, aunque desasociada, usando git checkout para consultarla directamente:

Cuando extraemos con checkout la confirmación desasociada, Git es lo suficientemente considerado como para mostrarnos un mensaje detallado explicando que estamos en un estado desasociado. Si examinamos el registro aquí, podemos ver que la confirmación “added another line to hello.txt” vuelve a aparecer en la salida del registro. Ahora que sabemos que el repositorio está en un buen estado de simulación con una confirmación desasociada, podemos practicar el uso de git prune. No obstante, volvamos antes de nada a la rama main usando git checkout.

Al volver a main mediante git checkout, Git vuelve a ser lo suficientemente considerado como para informarnos de que estamos dejando atrás una confirmación desasociada. ¡Ha llegado el momento de eliminarla! Ahora ejecutaremos git prune, pero debemos pasarle algunas opciones. --dry-run y --verbose mostrarán una salida que indica lo que está configurado para eliminarse pero sin eliminarlo realmente.

Lo más probable es que este comando devuelva una salida vacía, lo que implica que git prune no eliminará nada. ¿Por qué podría pasar esto? Bueno, lo más probable es que la confirmación no esté completamente desasociada. Git sigue manteniendo una referencia a ella en algún lugar. Este es un excelente ejemplo de por qué git prune no debe usarse de forma independiente fuera de git gc. También es un buen ejemplo de lo difícil que es perder datos por completo con Git.

Lo más probable es que Git esté almacenando una referencia a nuestra confirmación desasociada en el registro de referencias. Podemos investigar ejecutando git reflog. Deberías ver una salida que describa la secuencia de acciones que hemos llevado a cabo para llegar hasta aquí. Para obtener más información sobre git reflog, visita la página sobre git reflog. Además de conservar el historial en el registro de referencias, Git fija fechas de caducidad internas para determinar cuándo se eliminarán las confirmaciones desasociadas. Como vimos antes, estos son detalles de implementación de los que se encarga git gc, y git prune no debería usarse de forma independiente.

Para concluir nuestra demostración de simulación de git prune, tenemos que borrar el registro de referencias.

El comando de arriba forzará la caducidad de todas las entradas del registro de referencias que sean más antiguas que “now” (ahora). Este es un comando brutal y peligroso que nunca deberías tener que usar como usuario casual de Git. Estamos ejecutando este comando para ver cómo funciona git prune cuando se ejecuta correctamente. Con el registro de referencias totalmente borrado, ahora podemos ejecutar git prune.

Este comando debería mostrar una lista de referencias de objetos SHA de Git similar a la de arriba.

git prune tiene una breve lista de opciones de las que hemos hablado en la sección de descripción general.

No ejecuta git prune, solo muestra una salida de lo que hará.

Muestra una salida con todos los objetos y acciones que lleva a cabo git prune.

Muestra una salida que indica el progreso de la eliminación con git prune.

Fuerza la caducidad de los objetos que están en el pasado

Si especificas un ＜head＞, conservarás cualquier opción de esa referencia head

git remote prune y git fetch --prune hacen lo mismo: borran las referencias a las ramas que no están presentes en el repositorio remoto. Esto es muy conveniente cuando se trabaja en un flujo de trabajo de equipo en el que las ramas remotas se eliminan después de la fusión con main. El segundo comando, git fetch --prune, se conecta al repositorio remoto y recupera el estado remoto más reciente antes de llevar a cabo la eliminación. Se trata esencialmente de una combinación de comandos:

El comando genérico git prune es completamente diferente. Como vimos en la sección de descripción general, git prune elimina las confirmaciones desasociadas localmente.

git fetch --prune es la mejor utilidad para limpiar ramas obsoletas. Se conecta a un repositorio remoto compartido y recupera todas las referencias a ramas remotas. A continuación, elimina las referencias remotas que ya no se usan en el repositorio remoto.

No, git remote prune origin solo elimina las referencias a las ramas remotas que ya no existen. Git almacena referencias locales y remotas. Un repositorio tiene colecciones de referencias local/origin y remote/origin. git remote prune origin solo elimina las referencias en remote/origin. El trabajo local en local/origin no se modifica.

El comando git prune está pensado para invocarse como un comando secundario de git gc. Es muy poco probable que tengas que invocar git prune durante el trabajo diario de ingeniería de software. Hay que conocer otros comandos para entender los efectos de git prune. Algunos de los comandos utilizados en este artículo han sido git log, git reflog y git checkout.