Buscar..


Observaciones

El reflog de Git registra la posición de HEAD (la referencia del estado actual del repositorio) cada vez que se modifica. En general, cada operación que puede ser destructiva implica mover el puntero HEAD (ya que si se cambia algo, incluso en el pasado, el hash de confirmación de la punta cambiará), por lo que siempre es posible volver a un estado anterior, antes de una operación peligrosa , encontrando la línea derecha en el reflog.

Sin embargo, los objetos a los que no hace referencia ninguna referencia son generalmente basura recolectada en unos 30 días, por lo que es posible que el reflog no siempre pueda ayudar.

Recuperándose de una mala rebase

Supongamos que ha iniciado una rebase interactiva:

git rebase --interactive HEAD~20

y por error, usted aplastó o dejó caer algunos compromisos que no quería perder, pero luego completó la rebase. Para recuperarse, haga git reflog , y es posible que vea una salida como esta:

aaaaaaa HEAD@{0} rebase -i (finish): returning to refs/head/master
bbbbbbb HEAD@{1} rebase -i (squash): Fix parse error
...
ccccccc HEAD@{n} rebase -i (start): checkout HEAD~20
ddddddd HEAD@{n+1} ...
...

En este caso, la última confirmación, ddddddd (o HEAD@{n+1} ) es la punta de su rama pre-rebase . Por lo tanto, para recuperar esa confirmación (y todas las confirmaciones de los padres, incluidas las aplastadas o eliminadas accidentalmente), haga:

$ git checkout HEAD@{n+1}

Luego puede crear una nueva rama en ese commit con git checkout -b [branch] . Vea Ramificación para más información.



Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow