Git es el sistema de control de versiones más utilizado en la actualidad y realiza un seguimiento de los cambios de varias maneras para garantizar que nunca pierda un cambio confirmado. Además, el control que le brinda sobre los flujos de trabajo de desarrollo significa que puede determinar exactamente cómo se ve el historial de su proyecto. Git tiene varios mecanismos para reescribir el historial de confirmaciones para ayudar con esto, incluidos git commit --amend , git rebase y git reflog .

En este artículo, aprenderá cómo utilizar git reflog para reorganizar y reescribir su historial de confirmaciones de Git de manera eficaz y sencilla, al tiempo que mitiga el riesgo que a menudo conlleva reescribir el historial de confirmaciones.

¿Qué es un reflog?

Git usa un sistema llamado registro de referencia , o simplemente " reflog ", para realizar un seguimiento de las modificaciones en las sugerencias de las ramas. Una referencia, a menudo conocida como " ref ", es un puntero a una confirmación o rama que muchos comandos de Git aceptan como parámetro. git checkout , git reset y git merge son ejemplos de algunos comandos comunes de git que aceptan referencias como parámetros.

De forma predeterminada, los registros de referencia realizan un seguimiento de cada posición de HEAD durante los últimos 90 días. Además, el historial de reflog es exclusivo del repositorio y no es accesible de forma remota. Aparte de los registros de referencia de rama, hay un registro separado para el alijo de Git .

Los registros de referencia se almacenan en directorios específicos en el directorio .git del repositorio local. Estos directorios git reflog se pueden encontrar en .git/logs/refs/heads/. , .git/logs/HEAD y también .git/logs/refs/stash si se ha utilizado el git stash en el repositorio.

Configuracion basica

Los comandos básicos de reflog son los siguientes:

 # To see activity on HEAD git reflog show

El resultado del comando anterior es similar al siguiente:

 0a2e358 HEAD@{0}: reset: moving to HEAD~2 0254ea7 HEAD@{1}: checkout: moving from 2.2 to main c10f740 HEAD@{2}: checkout: moving from main to 2.2

Otros usos comunes son los siguientes:

 # To see activity on HEAD, including timestamp git reflog show --date=relative #or git reflog --relative-date # same, on some_branch git reflog show --date=relative some_branch

Referencias a Reflog

De forma predeterminada, git reflog genera el reflog de HEAD ref. El símbolo HEAD denota la rama actualmente activa. También hay reflogs disponibles para otros árbitros. La sintaxis utilizada para acceder a una referencia de git es name@{qualifier} , por ejemplo - otherbranch@{0} . Además de las referencias HEAD , también se pueden hacer referencia a otras ramas, etiquetas, controles remotos y alijo de Git.

Para ver el reflog completo de todas las referencias, puede ejecutar:

 git reflog show --all

Además de los índices ordenados, cada entrada de reflog tiene una marca de tiempo adjunta que también se puede aprovechar como un token calificador para la sintaxis del puntero de referencia de Git. Esto es lo que permite filtrar estas entradas de reflog por tiempo. Ejemplos de calificadores de tiempo de uso común incluyen:

• @{0}
• @{6.minutes.ago}
• @{2.hour.ago}
• @{3.day.ago}
• @{5.weeks.ago}
• @{8.years.ago}
• @{today}
• @{2022-01-23.08:30:00}
• @{1.day.10.hours.ago}

Estos calificadores de tiempo se pueden combinar (por ejemplo 1.day.3.hours.ago ). También se aceptan formas plurales de estos calificadores de tiempo (p. ej., 5.minutes.ago ). Se pueden usar junto con el comando git reflog de la siguiente manera:

 git reflog show develop@{3.days.ago}

Subcomandos y opciones de configuración

git reflog acepta algunos argumentos adicionales que, por lo tanto, se consideran subcomandos, como show , expire y delete . Analicemos estos subcomandos en detalle.

espectáculo de registro de git

Como se discutió anteriormente, show se pasa implícitamente por defecto. Ejecutar git reflog show mostrará el registro de los argumentos pasados.

Por ejemplo:

 git reflog develop@{0}

es lo mismo que

 git reflog show develop@{0}

Además, git reflog show es un alias de git log -g --abbrev-commit --pretty=oneline .

git reflog caducar

El subcomando expire ayuda a limpiar entradas de registro antiguas o inaccesibles.

El subcomando expire tiene el potencial de provocar la pérdida de datos.

Sin embargo, este subcomando no suele ser utilizado por los usuarios finales, sino por git internamente.

Se puede realizar una "ejecución en seco" pasando una opción -n o --dry-run para que git reflog expire para generar qué entradas de reflog están marcadas para ser eliminadas, de modo que no se eliminarán realmente. Esto puede ayudar como una red de seguridad mientras se limpian las entradas de reflog caducadas.

Además, el tiempo de caducidad se puede especificar pasando un argumento de línea de comando --expire=time to git reflog expire o estableciendo un nombre de configuración de git de gc.reflogExpire .

git reflog eliminar

El subcomando delete, como su nombre lo indica, elimina la entrada reflog pasada. Eliminar, como caducar, tiene el potencial de provocar la pérdida de datos y los usuarios finales no lo utilizan con frecuencia.

git reflog frente a git log

git reflog y git log son los dos componentes con nombres similares proporcionados por Git que nos permiten colarnos en el historial de confirmaciones, registros y reflogs del repositorio. El hecho de que los dos componentes a menudo muestren el mismo historial, especialmente cuando un desarrollador completa una serie de confirmaciones locales sin buscar ni extraer, es una de las razones de la confusión entre registros y reflogs de Git.

Sin embargo, estos son esencialmente diferentes y tienen diferentes casos de uso.

Comprendamos las diferencias subyacentes y las similitudes de los dos comandos anteriores.

La diferencia más notable entre Git reflog y log es que el registro es un registro público del historial de confirmaciones del repositorio, mientras que el reflog es un registro privado específico del espacio de trabajo de las confirmaciones locales del repositorio.

Después de empujar, buscar o extraer, el registro de Git se replica como parte del repositorio de Git. El reflog de Git, por otro lado, no está incluido en el repositorio duplicado. Sin acceso físico a la computadora donde se guarda el repositorio local, un desarrollador no puede examinar el registro de referencia.

El registro de referencia es un archivo que se encuentra en .git\logs\refs\heads que rastrea el historial de confirmaciones locales para una rama específica y excluye cualquier confirmación que pueda haber sido eliminada por los procesos de recolección de elementos no utilizados de Git. El registro de Git, por otro lado, proporciona un recorrido de confirmación histórico de una rama que comienza con la confirmación más reciente y concluye con la primera confirmación en la historia de la rama.

Git reflog como tu red de seguridad

Git reflog se puede usar como una red de seguridad durante el desarrollo, ya que no puede perder datos de su repositorio una vez que se ha confirmado si comprende el concepto de reflog correctamente. Puede usar el registro de referencia para ver dónde estaba antes y git reset --hard es difícil volver a esa referencia para restaurar su estado anterior si involuntariamente restablece a un compromiso anterior, rebase incorrectamente o realiza cualquier otra operación que "elimine" visiblemente se compromete

Recuerde que las referencias se refieren al historial completo de la confirmación, no solo a la confirmación en sí.

Conclusión

En este artículo, discutimos las opciones de configuración extendidas de git reflog , los casos de uso comunes y las trampas de git reflog .

Para resumir, Git mantiene un reflog, que es un registro de dónde han estado tus referencias HEAD y branch durante los últimos meses (90 días), en segundo plano mientras estás trabajando. Git guarda información en este historial temporal cada vez que se modifica la sugerencia de su sucursal por cualquier motivo.

El comando reflog también se puede usar para eliminar o hacer caducar las entradas que son demasiado antiguas del registro de reflog. El subcomando expire the se usa para eliminar las entradas obsoletas del registro de referencia y el subcomando delete se usa para eliminar y especificar la entrada específica que se eliminará del registro de referencia.