Encuentra un compromiso perdido con reflog

• Lea el reflog como el registro de este repositorio de dónde han estado HEAD y las ramas.
• Verifique el contenido de la confirmación de un candidato antes de rescatarlo.
• Cree una rama en el compromiso medido sin verificarla.
• Diga lo que el reflog no puede recuperar: trabajo no comprometido y entradas caducadas.

Está en private/lost-signup, una rama del resultado M de la lección 18. Comprometió una nota, "docs: mantenga la nota de recuperación de registro", que agregó docs/signup-recovery.md y luego ejecutó un restablecimiento completo de una confirmación. La nota desapareció de la sucursal, del gráfico y de tus archivos. Aún no tienes una rama de rescate y no cambiaste nada más.

Todo es local y en el plan gratuito (GitTree te pide que inicies sesión): sin cuenta de alojamiento, sin proveedor, sin Internet. Toda identidad es ficticia (ejemplo.com). Nunca ejecute esta lección en un proyecto real. El hard reset en la preparación es un ensayo en una copia desechable.

Realice los cambios en GitTree o con los comandos nativos de Git, no ambos en la misma copia. Leer el resultado siempre es seguro. Las etiquetas del menú provienen de las propias cadenas de GitTree 2.0 y los comandos nativos se ejecutaron con Git 2.43 en copias desechables. Los pasos GitTree no se ejecutaron en macOS, Windows o Linux.

El reflog es un diario local de los movimientos de los árbitros. HEAD tiene uno, al igual que cada rama. Registra "compromiso", "pago", "reinicio" y similares, con el compromiso al que llegó cada uno. Otro clon no tiene tu diario. Una confirmación de que todavía no pueden existir nombres de sucursales, y el reflog es la forma de encontrarlo.

Los selectores como HEAD@{1} cuentan las entradas a partir de ahora, por lo que cambian con cada operación posterior. Lea la acción, la hora, el ID y el expediente de un candidato antes de usarlo. No memorice una compensación como receta.

El reflog encuentra confirmaciones que se guardaron. No puede encontrar una edición que nunca se haya confirmado, como mostró la lección 27. Las entradas caducan: de forma predeterminada, Git mantiene las entradas para las confirmaciones que ninguna rama alcanza durante unos treinta días, y un repositorio puede cambiar eso. No ejecute comandos de limpieza o caducidad mientras se recupera.

Crear una rama en la confirmación agrega una referencia y nada más. La rama actual, el índice y sus archivos permanecen donde están.

Comience con una copia ordinaria separada del resultado M de la lección 18 y deje el original intacto. Cree la rama, guarde DOC_LOST, confirme y restablezca una confirmación. Esta preparación destructiva es sólo para una copia desechable.

Guarde solo en la fase que se menciona a continuación. Estos son cuerpos UTF-8/LF completos con una nueva línea final; Nunca pegues vallas Markdown. Los archivos ejecutables sin cambios heredan la entrada nombrada. Las versiones en variantes separadas no deben sobrescribir el original.

docs/signup-recovery.md — DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

Abra la paleta con Comando+Mayús+P (Ctrl+Mayús+P en Ubuntu).

1. Construya el ensayo como se muestra en la siguiente sección y observe el tema del compromiso perdido.
2. Abra la paleta y ejecute View Reflog…. El cuadro de diálogo "Reflog" se abre con Reflog of configurado en HEAD; las entradas se enumeran más nuevas primero.
3. Lea las entradas principales. El más nuevo dice "restablecer" y el de abajo dice "confirmar" con el asunto "docs: mantenga la nota de recuperación del registro". Utilice Show Older Entries si la lista es larga. No asumas que la segunda fila es siempre la correcta.
4. Seleccione la entrada de confirmación. El cuadro de diálogo muestra Show in Graph y New branch name. Show in Graph solo puede colocar una confirmación a la que llega una rama, por lo que para esta confirmación perdida cierra el cuadro de diálogo y el gráfico permanece en M: vuelve a abrir el registro para el siguiente paso. Lee el archivo de confirmación después de restaurarlo.
5. De nuevo en el cuadro de diálogo, seleccione la misma entrada, escriba rescue/signup en New branch name y elija Restore as Branch. El aviso dice "Se creó el rescate/registro de rama. Deshacer lo elimina nuevamente".
6. Verifique el resultado: rescue/signup puntos en la confirmación perdida, la rama actual todavía está private/lost-signup en M y sus archivos no han cambiado. Seleccione la confirmación restaurada y abra su archivo docs/signup-recovery.md: es DOC_LOST.
7. Deje la rama de rescate en su lugar. No ejecute ninguna limpieza para ordenar el gráfico.

Para cada confirmación ordinaria del curso: Summary es el asunto indicado, Description está vacío y las opciones Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit y Allow Empty Commit permanecen desactivadas.

Sólo en una copia limpia y separada del resultado de la lección 18:

git switch --create private/lost-signup

Guarde DOC_LOST como docs/signup-recovery.md y luego:

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: keep the signup recovery note"
git reset --hard HEAD~1
git reflog show --format=%gs -2 HEAD

reset: moving to HEAD~1
commit: docs: keep the signup recovery note

Enumere los candidatos con sus DNI y marque el que crea que está perdido:

git reflog show --format='%H %gs' HEAD
git show "<lost-sha>:docs/signup-recovery.md"

Reemplace <lost-sha> con el ID en la línea "commit: docs: mantenga la nota de recuperación del registro". En este ejemplo inmediato, HEAD@{1} es el mismo compromiso, pero ese desplazamiento no es una regla. Cree la rama de rescate sin verificarla:

git branch rescue/signup "<lost-sha>"
git show rescue/signup:docs/signup-recovery.md
git symbolic-ref --short HEAD
git status --short

El archivo es DOC_LOST, la rama impresa es private/lost-signup y el estado está vacío. Sus archivos no muestran la nota porque HEAD permaneció en M. Ningún comando de caducidad o limpieza forma parte de esto.

Where you end: rescue/signup apunta a la confirmación perdida y su archivo es DOC_LOST. La rama actual, el índice y sus archivos están exactamente como estaban después del reinicio y no se envió nada.

• Usar HEAD@{1} como receta fija en lugar de leer la entrada.
• Restablecer o retirar nuevamente antes de guardar una sucursal, lo que agrega más entradas y oculta la que desea.
• Esperando que el reflog contenga una edición que nunca se confirmó.
• Ejecutar comandos de limpieza mientras busca algo.

Si la confirmación no está en la lista, es posible que esté viendo la referencia incorrecta: cambie Reflog of entre HEAD y la rama, y use Show Older Entries. Si realmente desapareció, expiró o nunca se comprometió. En la aplicación, el aviso después de Restore as Branch dice Deshacer elimina la rama nuevamente.

Responda cada pregunta y luego lea por qué. Las preguntas marcadas como "Obligatorias" cuentan para completar la lección.

1. Pregunta 1 de 6

   Pregunta 1 de 6

   ¿Qué es el reflog?

   Elija una respuesta.

   Un registro compartido que cada clon y el servidor mantienen al día.

   Una copia de seguridad de tus archivos.

   Un registro local de hacia dónde han apuntado HEAD y cada sucursal.

   Lo mismo que el gráfico de confirmación.

   comprobar respuesta
2. Pregunta 2 de 6

   Pregunta 2 de 6

   ¿Cuáles de estas son ciertas para el reflog?

   Elija cada respuesta que corresponda.

   Almacena ediciones que nunca cometiste.

   HEAD y cada sucursal tienen la suya.

   Las entradas antiguas caducan.

   Otro clon del proyecto no tiene tus entradas.

   comprobar respuesta
3. Pregunta 3 de 6

   Pregunta 3 de 6Requerido

   Encontraste la confirmación perdida en el registro y usaste Restaurar como rama con el nombre rescue/signup. ¿Qué ves?

   Elija una respuesta.

   rescue/signup puntos en la confirmación perdida y todavía estás en private/lost-signup en M con tus archivos sin cambios.

   Ahora estás en rescue/signup y la nota vuelve a estar en tus archivos.

   private/lost-signup avanza hasta la confirmación perdida.

   La entrada de reflog se elimina.

   comprobar respuesta
4. Pregunta 4 de 6

   Pregunta 4 de 6

   Cambie la entrada: nunca confirmó la nota y luego ejecutó el restablecimiento completo. ¿Puede el reflog traerlo de vuelta?

   Elija una respuesta.

   Sí, a través de Mostrar entradas más antiguas.

   Sí, con HEAD@{1}.

   No. El reflog apunta a confirmaciones y este contenido nunca estuvo en una.

   Sí, cambiando Reflog a la sucursal.

   comprobar respuesta
5. Pregunta 5 de 6

   Pregunta 5 de 6Requerido

   Hiciste algunas operaciones más, luego ejecutaste git branch rescue HEAD@{1} y el archivo no es el que querías. ¿Qué pasó?

   Elija una respuesta.

   HEAD@{1} es siempre la confirmación correcta después de un reinicio.

   El reflog está corrupto.

   La nueva rama eliminó la confirmación perdida.

   HEAD@{1} cuenta hacia atrás a partir de ahora, por lo que cada nueva operación cambia su nombre. Lea la lista y utilice el ID de la confirmación perdida.

   comprobar respuesta
6. Pregunta 6 de 6

   Pregunta 6 de 6Requerido

   Después de crear la rama de rescate, ¿qué lecturas muestran que funcionó como dice la lección?

   Elija cada respuesta que corresponda.

   docs/signup-recovery.md ahora existe en tus archivos.

   git show rescue/signup:docs/signup-recovery.md imprime la nota recuperada, comenzando con "# Trabajo de registro recuperado".

   git status --short no imprime nada.

   git symbolic-ref --short HEAD imprime private/lost-signup.

   comprobar respuesta

Informe las dos líneas de reflog más recientes, el ID de la confirmación perdida, la primera línea del archivo recuperado y la rama en la que se encuentra su pago. Luego, diga qué mostraría el reflog para una edición que nunca realizó.

• El reflog es un diario local de movimientos de árbitros.
• Verifique el candidato y luego derive de él.
• Encuentra confirmaciones, no ediciones no guardadas.

• Restablecer: suave, mixto y duro (lección 27)
• Leer historial sin mover HEAD (lección 8)
• Descargar GitTree

Reflog — سجل المراجع; rama de rescate—فرع حفظ; selector — محدِّد.