Git Reset y Reflog: úsese en caso de emergencia
Contenido del curso
David Behar
Santa Karina Madre de Dios
David Behar
Jose Rodrigo Moreno Cordero
Andresa Helena Rivera Ceballos
JUAN SEBASTIAN RODRIGUEZ JIMENEZ
Angelo Paul Yenque Tume
Leslie Paz Ore
Esteban Gabriel Hainze
Valente IA
Leobardo Adrian Diaz Ruiz
Juan Christopher
Samuel Martínez Hernández
David Castro
Samuel Martínez Hernández
Patricio Cabrera
Ronnie Moncayo
Bryan Andres Gagñay Angamarca
Carlos Pernia
Tatiana Karina Valencia Hernández
Sneyder Barreto
Juan Pablo Perez
DARWIN JUAN CARLOS CATUNTA GARCIA
Alex Camacho
Profesor
Max Camargo
Eduardo Rodriguez
Wilmar Yoan Malaver Malaver
Fabian Mauricio Guerra Bedoya
Simón Holmquist
Platzi Team
Junior Antonio Coronación Mendoza
Wilson Delgado
Cynthia Rojas Rivera
Javier Eduardo Carrillo Abarca
Harold Giovanny Uribe Romero
Tomas Salina
Sebastian CA
Jimmy Buriticá Londoño
Juan Andres Garzon Garay
José Gregorio Block
Company_admin
CRISTIAN ANDRÉS BELTRÁN BOCANEGRA
Sebastián Andrés Sanhueza Tapia
Román Vázquez Beltrán
Horacio Gaido
Henry Alexander Velásquez Rosas
Leonardo Monastoque Abril
Fernando Alejandro Yerena Ramos
Enrique Montes Trejo
Ramiro Eduardo Fuentes
Leiver Granda
Francisco Ponce
Leiver Granda
Git nunca olvida, git reflog
Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo que estás haciendo sólo es actualizar la punta del branch, para gestionar éstas puntas existe un mecanismo llamado registros de referencia o reflogs.
.
La gestión de estos cambios es mediante los hash'es de referencia (o ref) que son apuntadores a los commits.
.
Los recoges registran cuándo se actualizaron las referencias de Git en el repositorio local (sólo en el local), por lo que si deseas ver cómo has modificado la historia puedes utilizar el comando:
git reflog
Muchos comandos de Git aceptan un parámetro para especificar una referencia o "ref", que es un puntero a una confirmación sobre todo los comandos:
git checkout Puedes moverte sin realizar ningún cambio al commit exacto de la ref
git checkout eff544f
git reset: Hará que el último commit sea el pasado por la ref, usar este comando sólo si sabes exactamente qué estás haciendo
git reset --hard eff544f # Perderá todo lo que se encuentra en staging y en el Working directory y se moverá el head al commit eff544f git reset --soft eff544f # Te recuperará todos los cambios que tengas diferentes al commit eff544f, los agregará al staging area y moverá el head al commit eff544f
git merge: Puedes hacer merge de un commit en específico, funciona igual que con una branch, pero te hace el merge del estado específico del commit mandado
git checkout master git merge eff544f # Fusionará en un nuevo commit la historia de master con el momento específico en el que vive eff544f
Oiga joven usted se merece la medalla a héroe sin capa, siempre voy a los comentarios para ver si hay una aportación suya jaja
Oh, gracias santakarinamadrededios, me motivas a seguir haciendo las aportaciones
Freddy son las 3:43 AM y estoy vienod el video a esta hora porque hace 40 minutos hice un merge que genero conflicto y se sobreescribio mis cambios en un intento de recuperara el trabajo con VS2019 lo que hice fue borrar todo. No sabe como le agradezco esta clase, de verdad pensé que había perdido el trabajo de mas de 30 horas seguidas todo el fin de semana con su festivo incluido, justo 6 horas antes de tener que entregarlo. Esta es la clase que por mucho me ha ayudado a que no fuera la peor semana de este año. Mil Millones de Gracias , de verdad, creo que se nota mi agradecimiento, estaba realmente desesperanzado
Como solucionaste tu problema? Estoy segura de que entenderlo ayudara a muchos estudiantes para que no les suceda lo mismo
Qué buena historia, sufrí mientras leía el comentario.
==Antepenúltimo aporte de este curso! :) ==
Buena compañero, tus apuntes me han sido súper útiles para repasar todas las clases.
Muchas gracias!!
Flanders!!, porque borraste todo....
XD
Lol xD
Cuando haces un git commit --amend cuando la cagaste y pensaste que tu jefe no se enteraría:
Cuando te enteras de que existe el git reflog:
Saludos! Sam Martínez(￣﹃￣)
XD Nada se le escapa a Git
@DavidAlejo jajaja no! es poderoso
Cabecera queda eliminada porque se le hace reset a master, para recuperar cabecera podemos conseguir el commit con reflog e usar
git checkout -b cabecera "commit id"
Muchas gracias!
Muchas gracias por el aporte, pense que lo estaba haciendo mal ya que no recuperaba la rama.
git reset --HARD Antes de conocerla a ella
HAHAHAHAHAHAHA
Freddy viendo cómo uso git reset --hard a lo loco porque YOLO. Jk.
jajajajaja
hahahaha
Reflog
Los registros de referencia también llamados reflogs son una funcionalidad de git que registra todos los eventos del repositorio. Cada vez que el extremo de tu rama se actualiza por cualquier motivo, se añade una nueva entrada a este registro.
→ Mostrar el registro.
$ git reflog
→ Mostrar el registro relativo a la fecha especificada.
$ git reflog --relative-date
Reset
Este comando borra toda la información de nuestra rama hasta el punto que le especifiquemos. La invocación predeterminada tiene argumentos implícitos, como lo detallo a continuación:
→ Invocación predeterminada del comando
$ git reset
→ Invocación con sus argumentos implícitos.
$ git reset --mixed HEAD
En vez de HEAD, se puede usar cualquier HASH de commit de git.
Además del argumento --mixed tenemos otros dos que son --hard y --soft.
Ahora, detallando un poco cada uno de los argumentos tendríamos lo siguiente:
--hard → Esta es la opción más peligrosa aunque es la que se usa más frecuentemente. Con esta opción todo el trabajo que se encuentra en el staged se pierde y la cabecera de nuestro repositorio apuntará al commit indicado olvidándose de todo lo que sucedió después de ese commit.--mixed → Este es el modo de funcionamiento predeterminado. Se actualizan los punteros del repositorio y todos los cambios que se hayan deshecho en el índice del entorno de ensayo e mueven al directorio de trabajo.--soft → En esta opción a diferencia de la primera todo lo que estaba en el staged se conserva, únicamente actualiza la cabecera del repositorio al commit indicado.Que gran aporte!!! muchas gracias :)
Muy buen aporte, gracias
Para los que se les perdio la rama cabecera solo ejecuten git checkout cabecera, luego git checkout master de nuevo y git branch ahí ya aparece cabecera de nuevo.
Buen aporte! no lo encontraba
sos un maldito genio
Visual studio code fue hecho con el amor de una madre. ☺️
xd cmamo fredy
Git reflog lo sabe todo...
Yo viendo con reflog todos los reset que había hecho antes de llegar a la clase de los reset xd
jajajaja epico
Cuando el pinche bug no se puede solucionar!!! xD
Es increible como Git guarda absolutamente todo lo que hicimos en nuestro repositorio. Incluso luego de hacer un git reset --hard, podemos volver al momento exacto antes de hacerlo. Un dato interesante es que tu reflog nunca será igual al de otra persona, aún cuando esa persona esté trabajando en el mismo proyecto que tú. La razón es que Git solamente sube al servidor (GitHub por ejemplo) las referencias que se puedan acceder directamente. Es decir, cuando estamos haciendo un push no estamos mandando el reflog, el reflog solo vive en nuestra máquina, y el servidor tiene su propio reflog. Por lo tanto, Git no es un sistema de opias de seguridad, hacer un push no es hacer una copia de seguridad al repositorio.
De verdad muchas gracias,voy a anotar esto :D
Excelente aporte
#Gracias
gracias ☺
Hola a todos, fui anotando todos los comandos del curso y los agrupé en categorías y como no podía ser de otra forma, los subí a GitHub, seria genial, que ustedes añadiesen los comandos que quisieran y/o sus propias descripciones con un pull requests https://github.com/SuKuShaing/ComandosDeGit.git
Oro molido!!! Le hice un fork. Muchas gracias por el aporte
Gran aporte! Gracias!
Apuntes 😄
excelentes apuntes
Para recuperar una rama que haya sido eliminada necesitamos el hash ultimo commit hecho en dicha rama. Para eso usamos git reflog. Buscamos el hash y lo copiamos.
Ya habiendo obtenido el hash lo que hacemos sera volver a crear la rama pero le agregamos el hash al final.
git checkout -b cabecera hash_del_utlimo_commit_de_cabecera
excelente
Excelente aporte, muchas gracias.
Hm, cabecera no aparece con en el git branch hasta que le haces checkout.
Hola Leiver,
Te refieres a que no vas a esa rama hasta que ejecutas gco -b ?
Hola Francisco, me refiero git checkout cabecera así no más, ya que con el argumento -b creas una nueva rama. luego de hacerle el checkout y hacer git branch aparece.
En el ejemplo Freddy hace git branch y cabecera no aparece en la lista, yo al principio me asusté pero con el checkout aparece. :)