Tecnología · GUÍA PRÁCTICA
¿Falló git stash pop? Revisa la restauración parcial antes de limpiar
Un archivo con el mismo nombre puede bloquear la restauración de archivos sin seguimiento aunque los cambios de archivos rastreados ya se hayan aplicado. Conserva ambas versiones, identifica el stash exacto y compara el resultado antes de borrar.
Un error al restaurar un stash no demuestra que el árbol de trabajo siga intacto. Primero conserva el estado actual y determina qué hizo la operación fallida. Trata el archivo local y su equivalente guardado como versiones distintas hasta compararlos.
1. Conserva las pruebas antes de reintentar
Guarda el error completo, el comando, la versión de Git, la rama, la lista de stashes y el estado actual. Revisa git status --short --untracked-files=all --ignored y los cambios tanto preparados como sin preparar. Mostrar los ignorados importa: un estado aparentemente limpio no demuestra que no exista una colisión ignorada. Antes de modificar rutas, conserva por separado los archivos locales valiosos y todos los datos de Git. Un clon normal o un diff exportado no preserva automáticamente cada stash y archivo sin seguimiento.
En un repositorio sintético aislado con Git 2.51.1, guardamos con -u una modificación rastreada y un archivo sin seguimiento; después creamos contenido local diferente en esa misma ruta. Pop devolvió el código 1: el cambio rastreado ya estaba aplicado, la colisión local seguía intacta y se conservaba el stash exacto. Esto demuestra un posible resultado parcial, no lo ocurrido en tu repositorio ni una garantía para todas las versiones.
2. Identifica el stash y clasifica cada colisión
Elige la entrada deseada en git stash list y registra su ID completo con git rev-parse --verify, usando la referencia elegida y el sufijo ^{commit}. Sustituye la selección real; no supongas que la entrada más nueva es la correcta. Inspecciona el ID registrado con git stash show --include-untracked --patch y, si tu versión lo admite, --only-untracked --name-only. Conserva la entrada original: su posición numérica puede cambiar.
Compara cada ruta indicada con el índice y los archivos actuales. ¿Ahora está sin seguimiento, ignorada o rastreada en esta rama? ¿Se incluyó al crear el stash? Su clasificación puede haber cambiado. Atlassian explica que el contenido sin seguimiento capturado se almacena por separado en la estructura del stash; no todos los stashes tienen ese componente. No apliques una receta general del tercer padre ni sobrescribas antes de averiguar qué contenido tienes.
3. Recupera en un lugar controlado y compara
Tras verificar una preservación independiente, mueve la colisión local valiosa a un lugar claramente identificado fuera de la ruta de recuperación, en vez de borrarla. Antes de aplicar el stash otra vez, ten en cuenta los cambios rastreados ya aplicados: mover la colisión no deshace ese resultado parcial. Si el árbol de trabajo es incierto, recupera en una copia independiente del repositorio con todos los objetos pertinentes de Git y una copia de trabajo limpia, sin tocar el original.
Git stash branch puede reconstruir el trabajo desde la base original del stash, lo que ayuda si la rama actual avanzó. Sigue la documentación instalada y usa una rama de recuperación distinta en la copia preparada. Una copia de trabajo con cambios puede bloquear la operación. Una recuperación exitosa con un nombre stash@{n} puede eliminar esa entrada; conserva antes el repositorio original y su identidad exacta. Compara los archivos recuperados con las copias locales guardadas y con el diff rastreado ya aplicado, y combina deliberadamente.
4. Decide la eliminación por separado
Confirma los contenidos rastreados, sin seguimiento e ignorados necesarios, y el estado del índice si era importante. Ejecuta la compilación o las pruebas previstas. Registra dónde está cada versión conservada y qué diferencias elegiste. Una aplicación exitosa no demuestra que todos los archivos deseados se guardaran originalmente. Apply mantiene el stash; que siga ahí no significa que no se restaurara nada.
Solo elimina la entrada cuyo nombre actual hayas cotejado con el ID registrado, después de verificar la recuperación. Evita empezar con git clean -xfd general o un checkout forzado: pueden borrar contenido necesario para comparar. Una simulación de clean limitada a rutas muestra candidatos, pero no los respalda. Si falta una versión necesaria o el resultado parcial sigue sin explicación, conserva las pruebas y el stash en vez de declarar terminada la recuperación.
