¿Puedo ver el registro de referencia de un control remoto (no una referencia remota)?

Preguntas GIT
⏰ 5 minutos de lectura

Avatar de usuario de Alexander Bird
alexander pájaro

¿Es posible ver el reflog de un control remoto? Es decir, quiero saber cuál es la salida de git reflog está en otra máquina remota.

Tenga en cuenta que no estoy solicitando el reflog de ramas de seguimiento remoto (como origin/master); estoy preguntando por que reflog dice en la otra maquina.

  • Si tiene acceso al sistema de archivos del sistema remoto (que a menudo es un repositorio simple), siempre tiene la opción de ejecutar git reflog allí. Pero tener dicho acceso normalmente no es posible. Tengo la costumbre de hacer esto posible en los servidores git (usando un recurso compartido de archivos de solo lectura), solo para que sea posible revisar el reflog en el lado del servidor.

    –Anders Zommarin

    30 de julio de 2014 a las 11:51

Avatar de usuario de Błażej Czapp
Blazej Czapp

En caso de que la máquina remota sea un repositorio de github,

  1. Primero use la API de eventos de Github para recuperar el SHA de confirmación.
    curl https://api.github.com/repos/<user>/<repo>/events

  2. Identifica el SHA del id de compromiso huérfano que ya no existe en ninguna rama.

  3. A continuación, use la API Refs de Github para crear una nueva rama que apunte a la confirmación huérfana.

    curl -i -H "Accept: application/json" -H "Content-Type: application/json" -X POST -d '{"ref":"refs/heads/D-commit", "sha":"<orphan-commit-id>"}' https://api.github.com/repos/<user>/<repo>/git/refs

    Reemplazar <orphan-commit-id> en el comando anterior con el SHA identificado en el paso 2.

  4. Finalmente git fetch la rama recién creada en su repositorio local.
    A partir de ahí, puede seleccionar o fusionar las confirmaciones nuevamente en su trabajo.

Verificar Este artículo para un ejemplo real.

  • ¡Muchas gracias! Para aquellos menos inclinados a usar la línea de comando, también pueden omitir el paso 3 simplemente abriendo github.com///commits/…> y cree una nueva rama directamente en el menú desplegable “Árbol:”. Entonces solo tráelo normalmente.

    – Waldyrious

    15 de septiembre de 2016 a las 7:45

  • si obtienes un "message": "Not Found" error, esto significa que necesita autenticarse, por ejemplo, pasando una cadena de consulta access_token.

    –Andy Hayden

    7 de marzo de 2017 a las 6:39

  • Para mí, la forma más fácil de rastrear el SHA del id de compromiso huérfano fue mirar la última compilación en CircleCI (o [insert CI service here]).

    – samjewell

    24 de marzo de 2017 a las 13:57

  • Parece que esta respuesta aborda un problema diferente al que plantea la pregunta. Parece que aborda cómo recuperar una confirmación a la que ya no se puede acceder desde ninguna rama o etiqueta, mientras que la pregunta pregunta cómo ver el registro de referencia: el historial al que se refiere una rama o etiqueta.

    – Matt McClure

    25 de junio de 2020 a las 5:47

  • Para que quede claro, para los futuros lectores, desea agregar -u <github username>:<github personal access token> al comando en 3.

    – Daniel Porteous

    11 de marzo de 2022 a las 3:46

La respuesta es básicamente “no” (excepto en esa máquina), porque el reflog es un registro de reasignaciones locales de algún nombre de referencia. Esencialmente, cada vez que corres git update-ref -m msg <name> <target> la actualización se registra… localmente: .git/logs/<name> obtiene una línea adjunta:

$ git update-ref -m foo HEAD HEAD^
$ tail -1 .git/logs/HEAD
2418b6ba8fd0289933c9351260a272b8e410867f 8d945134b0cead535d66af29c8eb4228b5dc3763 [redacted] <[redacted]> 1334106483 -0600     foo

(la cosa antes del mensaje, en este caso foo, no son espacios sino un tabulador; Lo expandí para fines SO). Conceptualmente, todo lo demás que mueve la punta de una rama invoca git update-ref para hacerlo (algunos son scripts de shell y literalmente hacen eso, otros simplemente invocan el código C que hace toda la actualización de archivos) … y todo en .git/logs compone el reflog.

Si hubiera cosas en los protocolos git:// y/o ssh:// subyacentes que le permitieran acceder al reflog, eso sería suficiente, pero que yo sepa, no lo hay.

En GitHub, si por error hiciste un git push --force en el maestro antes de obtener los cambios combinados y, mientras tanto, se eliminó la rama combinada (sí, me pasó a mí), puede buscar la solicitud de extracción combinada e ir a la confirma sección, por ejemplo:

ingrese la descripción de la imagen aquí

Luego vas a la última confirmación y haces clic en el <> botón (que tiene el título “Examinar el repositorio en este punto del historial”).

Esto lo llevará al punto “eliminado” de la historia. Desde aquí puedes:

  • cree una nueva rama y luego abra una nueva solicitud de extracción (recomendado si el cambio proviene de otro repositorio).
  • abra una nueva solicitud de extracción (recomendado para confirmaciones dentro de su repositorio).

  • Otra solución es usar git push --force-with-lease pensamientobot.com/blog/git-push-force-with-lease

    –Othmane El Kesri

    15 oct 2019 a las 16:23

  • Para usuarios de Gitlab: puede copiar el SHA ID de confirmación de la última confirmación antes de la reorganización, ir a la página del proyecto, hacer clic en el icono “+” junto al nombre del repositorio, hacer clic en “Nueva rama” y pegar la última ID de confirmación . Ahora puede consultar esta nueva sucursal localmente o crear un MR.

    – Letik

    1 de marzo de 2022 a las 17:01

Puede usar este comando para ver registros remotos:

git reflog refs/remotes/<remote name>/<branch name>

Entonces, si su control remoto se llama “origen” y su rama es “tortugas”:

git reflog refs/remotes/origin/turtles

¿Ha sido útil esta solución?