Aprende a recuperar commits borrados con git reflog y a volver atr\u00e1s con seguridad en Git antes de perder trabajo valioso.<\/p>\n
Perder un commit puede generar un buen susto, sobre todo cuando has trabajado durante horas y piensas que el historial se ha quedado \u201climpio\u201d para siempre. La buena noticia es que, en Git, borrar no siempre significa perder. Cuando un commit desaparece de la rama visible, todav\u00eda puede seguir accesible durante un tiempo gracias a git reflog<\/strong>.<\/p>\n Este comando es una especie de diario interno de referencias: registra a d\u00f3nde han apuntado HEAD<\/em> y las ramas locales en cada movimiento. Por eso, cuando te equivocas con un git reset<\/strong>, cambias de rama y parece que un commit se ha esfumado, reflog<\/strong> suele ser la herramienta que marca la diferencia. Si te interesa repasar primero cu\u00e1ndo conviene deshacer cambios sin riesgo, puedes echar un vistazo a C\u00f3mo deshacer cambios en Git sin perder tu trabajo<\/a>.<\/p>\n Git no solo guarda el historial de los commits; tambi\u00e9n registra los movimientos de las referencias locales. Cada vez que avanzas, retrocedes, haces checkout, ejecutas un reset o reescribes el historial, Git anota ese cambio en el reflog.<\/p>\n En la pr\u00e1ctica, eso significa que puedes recuperar el puntero a un commit anterior aunque ya no aparezca en git log<\/strong>. Esta diferencia es importante: Hay varios escenarios t\u00edpicos en los que reflog te puede rescatar:<\/p>\n \u2022 Has ejecutado git reset –hard<\/strong> y borraste commits que todav\u00eda necesitabas. Tambi\u00e9n es \u00fatil al trabajar con ramas locales. Si quieres revisar primero c\u00f3mo se comportan las referencias en Git, conviene tener claro qu\u00e9 son las ramas y c\u00f3mo avanzan, algo que tratamos en qu\u00e9 son las ramas en Git y c\u00f3mo funcionan<\/a>.<\/p>\n El comando b\u00e1sico es sencillo:<\/p>\n La salida suele mostrar entradas como estas:<\/p>\n Cada l\u00ednea te da una pista. El valor con formato Si recuerdas aproximadamente cu\u00e1ndo hiciste la acci\u00f3n, revisa las \u00faltimas entradas de Cuando localices el punto correcto, tienes dos caminos: moverte temporalmente a ese commit o crear una rama nueva para no perder tu estado actual. En entornos de trabajo reales, esta segunda opci\u00f3n suele ser la m\u00e1s prudente.<\/p>\n Supongamos que encuentras en el reflog el hash Esto sirve para comprobar que realmente era el punto que buscabas. Pero si quieres conservarlo de forma segura, lo ideal es crear una rama nueva:<\/p>\n Despu\u00e9s puedes cambiarte a ella con normalidad:<\/p>\n Si el objetivo era devolver tu rama principal a ese estado, tambi\u00e9n puedes mover la referencia con un reset, pero hazlo con cuidado. Si necesitas repasar las diferencias entre estrategias de deshacer cambios, te resultar\u00e1 \u00fatil c\u00f3mo utilizar git reset correctamente<\/a> y, cuando lo que quieres es crear una correcci\u00f3n inversa sin reescribir historia, c\u00f3mo revertir un commit con git revert<\/a>.<\/p>\n Imagina que ejecutaste:<\/p>\n Despu\u00e9s, revisas:<\/p>\n Y finalmente recuperas el estado:<\/p>\n Este procedimiento es especialmente \u00fatil cuando el commit conten\u00eda cambios valiosos que todav\u00eda no hab\u00edas enviado al remoto. Para entender mejor el flujo entre repositorio local y remoto, tambi\u00e9n conviene recordar c\u00f3mo funciona git push<\/a> y cu\u00e1ndo usar git pull<\/a> o git fetch<\/a>.<\/p>\n El reflog no es eterno. Git conserva estas referencias durante un tiempo limitado y, con el mantenimiento del repositorio, entradas antiguas pueden desaparecer. Si el commit ya no est\u00e1 en el reflog local, la recuperaci\u00f3n se complica, aunque todav\u00eda puede haber alternativas dependiendo de si el commit se lleg\u00f3 a compartir con otras personas o con un remoto.<\/p>\n En ese caso, conviene revisar si el commit fue subido a un servidor, si otro compa\u00f1ero lo tiene en su copia local o si existe alguna referencia en una rama remota. Aqu\u00ed cobra valor tener bien organizados los repositorios y saber c\u00f3mo gestionarlos, tal como se explica en c\u00f3mo gestionar repositorios remotos con git remote<\/a> y c\u00f3mo conectar Git con GitHub paso a paso<\/a>.<\/p>\n El reflog es potent\u00edsimo, pero no deber\u00eda ser tu \u00fanico plan de seguridad. Algunas pr\u00e1cticas ayudan a evitar sustos:<\/p>\n \u2022 Crea ramas temporales antes de hacer operaciones destructivas. Si quieres profundizar en higiene de trabajo con Git, tambi\u00e9n merece la pena consultar c\u00f3mo consultar el estado del repositorio con git status<\/a> y c\u00f3mo a\u00f1adir archivos al repositorio con git add<\/a>, porque una buena disciplina diaria reduce mucho la probabilidad de tener que recuperar commits borrados.<\/p>\n El error m\u00e1s habitual es asumir que basta con mirar el hash y ejecutar cualquier comando sobre \u00e9l sin comprobar el contexto. No todos los movimientos del reflog representan un commit \u00fatil para volver a una rama estable.<\/p>\n Otro fallo frecuente es usar git reset –hard<\/strong> justo despu\u00e9s de encontrar el commit perdido, sin haber creado antes una rama de rescate. Si algo sale mal, habr\u00e1s vuelto a mover la referencia y te tocar\u00e1 repetir el proceso. Tambi\u00e9n es com\u00fan confundir la recuperaci\u00f3n de un commit con la restauraci\u00f3n de archivos concretos; para eso, el enfoque cambia y puede ser mejor usar c\u00f3mo recuperar archivos con git restore<\/a>.<\/p>\n git reflog<\/strong> es una de esas herramientas que pasan desapercibidas hasta que realmente las necesitas. Cuando un commit parece perdido, ofrece una segunda oportunidad para encontrarlo, inspeccionarlo y restaurarlo con seguridad.<\/p>\n La clave est\u00e1 en entender que Git guarda m\u00e1s informaci\u00f3n de la que muestra a simple vista. Con una lectura correcta del reflog y una estrategia prudente \u2014normalmente crear una rama antes de hacer cambios definitivos\u2014 puedes recuperar commits borrados sin convertir el incidente en una p\u00e9rdida real de trabajo.<\/p>\n Documentaci\u00f3n oficial de git reflog<\/a><\/p>\nQu\u00e9 es git reflog y por qu\u00e9 salva commits<\/h2>\n
git log<\/code> muestra el historial visible de una rama, mientras que git reflog<\/code> ense\u00f1a sus movimientos recientes, incluso los que ya no forman parte de la l\u00ednea principal. Si quieres reforzar esta idea, tambi\u00e9n ayuda entender c\u00f3mo ver el historial de cambios con git log<\/a>.<\/p>\nCu\u00e1ndo resulta \u00fatil<\/h3>\n
\n\u2022 Hiciste un checkout a otra rama y perdiste la referencia visual de tu trabajo.
\n\u2022 Reescribiste la historia con un rebase o un reset y quieres volver al punto anterior.
\n\u2022 Fusionaste cambios, pero despu\u00e9s descubres que deb\u00edas conservar una versi\u00f3n previa.<\/p>\nC\u00f3mo ver el reflog paso a paso<\/h2>\n
git reflog\n# Muestra el historial reciente de movimientos de HEAD y referencias locales<\/code><\/pre>\ne3a1b2c HEAD@{0}: reset: moving to HEAD~1\nf9d4a88 HEAD@{1}: commit: Corrige validaci\u00f3n del formulario\n7c2d901 HEAD@{2}: checkout: moving from main to feature\/login<\/code><\/pre>\nHEAD@{n}<\/code> representa una posici\u00f3n anterior de la referencia actual. El hash de commit que aparece al inicio es el que puedes usar para volver a ese estado.<\/p>\nIdentificar el commit correcto<\/h3>\n
git reflog<\/code> hasta encontrar el commit que quieres recuperar. Si no recuerdas el hash exacto, puedes apoyarte en la descripci\u00f3n del movimiento: commit<\/em>, reset<\/em>, checkout<\/em> o merge<\/em>.<\/p>\nRecuperar un commit borrado sin riesgos<\/h2>\n
7c2d901<\/code>. Puedes inspeccionarlo as\u00ed:<\/p>\ngit checkout 7c2d901\n# Te lleva a ese commit en modo detached HEAD<\/code><\/pre>\ngit branch recuperacion-commit 7c2d901\n# Crea una rama que apunta al commit recuperado<\/code><\/pre>\ngit switch recuperacion-commit\n# Vuelves al estado rescatado y puedes seguir trabajando desde ah\u00ed<\/code><\/pre>\nEjemplo pr\u00e1ctico de recuperaci\u00f3n<\/h3>\n
git reset --hard HEAD~1\n# Se elimina el \u00faltimo commit de la rama visible<\/code><\/pre>\ngit reflog\n# Localiza el hash del commit perdido antes del reset<\/code><\/pre>\ngit branch rescate f9d4a88\ngit switch rescate\n# El commit vuelve a estar accesible desde una rama<\/code><\/pre>\nQu\u00e9 hacer si el commit ya no aparece en reflog<\/h2>\n
Buenas pr\u00e1cticas para no depender solo de la suerte<\/h3>\n
\n\u2022 Comprueba el estado con frecuencia usando git status<\/code>.
\n\u2022 Usa commits peque\u00f1os y descriptivos para que sea m\u00e1s f\u00e1cil localizar cambios.
\n\u2022 Evita reescribir historia en ramas compartidas sin coordinarte con el equipo.<\/p>\nErrores comunes al usar git reflog<\/h2>\n
Conclusi\u00f3n<\/h2>\n
Fuentes y lecturas recomendadas<\/h3>\n