Git stash pop: conserva tu trabajo al cambiar de rama

Si tienes trabajo a medias que aún no está listo para hacer commit, pero necesitas cambiar de contexto ya, no hagas un commit de "WIP". Tampoco copies y pegues tus cambios en un archivo de texto como si estuviéramos en 2005. git stash es todo lo que necesitas.

Este comando es la forma ideal de conservar cambios sin confirmar mientras cambias de contexto. Te permite guardar cambios temporalmente, atender tareas urgentes en otras ramas y restaurarlo todo exactamente donde lo dejaste.

En este artículo, te explico cómo funciona git stash pop, cuándo usarlo frente a git stash apply y cómo recuperarte cuando inevitablemente aparezcan conflictos.

Si eres nuevo en Git y el concepto de stash te confunde, asegúrate de dominar primero los fundamentos. Nuestros cursos Introduction to Git e Introduction to GitHub te pondrán al día en nada.

Entender Git stash

Git stash es un almacenamiento temporal para cambios sin confirmar.

Piénsalo como el portapapeles de tu trabajo. Tienes cambios en tu directorio de trabajo que aún no están listos para commit, pero necesitas cambiar de rama o traer actualizaciones del remoto. En lugar de perder tu trabajo o hacer un commit WIP, lo mandas al stash.

El comando guarda tus modificaciones y revierte tu directorio de trabajo para que coincida con el commit HEAD.

La idea del stash en Git

El stash resuelve un problema sencillo: Git no te deja cambiar de rama con cambios sin confirmar.

Imagina que estás desarrollando una funcionalidad cuando llega un bug. Necesitas cambiar de rama ya, pero tienes código a medio escribir y archivos modificados. No tiene sentido hacer commit porque tu trabajo está incompleto. Un checkout forzado te haría perder los cambios.

Ahí es cuando haces stash.

Estos son los escenarios más comunes en los que el stash te ayuda:

1. Cambiar de rama por trabajo urgente: estás en mitad de una feature cuando tienes que arreglar un bug en producción.
2. Traer cambios del remoto: tu compañero subió actualizaciones y necesitas hacer pull, pero tienes modificaciones locales.
3. Evitar commits desordenados: no estás listo para hacer commit, pero quieres un árbol limpio para rebase o merge.
4. Guardar código experimental: quieres probar otro enfoque sin perder tu trabajo actual

Hacer stash es rápido y reversible: no hace falta pensar en mensajes de commit ni en nombres de ramas.

La pila del stash

Git mantiene los stashes en una pila LIFO (último en entrar, primero en salir).

Cada vez que haces stash, Git crea una nueva entrada arriba de la pila. El stash más reciente es stash@{0} y los anteriores bajan: stash@{1}, stash@{2}, etc.

Por debajo, cada stash es en realidad un commit —o, más exactamente, un conjunto de commits. Git crea una estructura de commit multipadre que almacena:

1. Tus cambios en el directorio de trabajo
2. Tus cambios indexados (el área de staging)
3. Archivos no rastreados (si usaste la bandera u)

Esto significa que los stashes no son simples instantáneas. Son commits completos que Git puede fusionar de nuevo en tu directorio de trabajo más tarde.

Puedes referenciar stashes de dos formas: por índice usando la sintaxis stash@{0}, o con git stash list para encontrar el mensaje que les diste y referenciar ese stash concreto. El índice es más rápido para los recientes, pero los mensajes son mejores cuando tienes varios guardados.

Así se ve una pila de stashes típica:

El prefijo WIP on significa que usaste git stash sin mensaje. El prefijo On indica que proporcionaste un mensaje personalizado con git stash push -m.

Los stashes viven solo en tu repositorio local: no se suben al remoto. Así tu trabajo temporal se queda donde debe: en tu máquina, listo para restaurar cuando lo necesites.

Crear, gestionar y examinar stashes

El comando git stash básico te saca del paso, pero es perezoso. Terminarás con una pila de entradas tipo "WIP on branch-name" que no te dicen nada. Seis semanas después, no recordarás qué stash tiene el arreglo del bug y cuál el refactor a medias.

Vamos a ver cómo hacerlo bien desde el principio.

Crear stashes con buen contexto

La forma más simple de hacer stash es escribir git stash:

git stash

Esto guarda tus cambios, pero el mensaje "WIP on main" no es muy informativo. No puedes saber qué hay dentro sin inspeccionarlo.

En su lugar, ejecuta git stash push -m con un mensaje descriptivo:

git stash push -m "Actualizado file.txt"

Ahora tu lista de stashes sí es informativa:

La diferencia salta a la vista. Una entrada te dice exactamente lo que hiciste, la otra te hace adivinar.

Escribe mensajes como si fueran notas para tu yo del futuro. "Añadir lógica de auth", "Arreglo del bug en la navbar" o "Prueba de nuevo diseño de API" siempre superan a los WIP genéricos.

Incluir archivos no rastreados o ignorados

Por defecto, git stash solo guarda archivos rastreados —los que Git ya conoce.

Los no rastreados se quedan en tu directorio de trabajo. Mucha gente se sorprende cuando hace stash, cambia de rama y ve sus archivos nuevos aún ahí.

Esto es lo que pasa:

echo "new_feature.py" > new_feature.py
git stash

El archivo no se guardó en el stash porque Git aún no lo rastrea:

Para solucionarlo, usa la bandera -u para incluir archivos no rastreados:

git stash push -u -m "Añadido un archivo Python para una feature chula"

Esto guarda en el stash tanto archivos rastreados como no rastreados. Tu directorio de trabajo queda totalmente limpio.

Consejo: puedes añadir la bandera -a para incluir también los ignorados. Guarda en el stash los rastreados, los no rastreados y los que estén en tu .gitignore. Rara vez lo necesitarás salvo que estés depurando builds o quieras una instantánea totalmente limpia de todo.

Aquí tienes una chuleta para saber cuándo usar cada bandera:

1. Sin bandera: solo cambiaste archivos existentes

2. u (flag): añadiste archivos nuevos que aún no se rastrean

3. a (flag): necesitas guardar todo, incluidos artefactos de build o temporales

La mayoría de las veces usarás -u. Es la apuesta segura cuando has creado archivos nuevos durante el desarrollo.

Hacer stash parcial o selectivo

No tienes que guardar todo lo que hay en tu directorio de trabajo.

Digamos que arreglaste dos bugs, pero solo quieres guardar uno. O tienes cambios en cinco archivos, pero solo tres pertenecen a la feature que quieres salvar.

Puedes hacer stash de archivos concretos con pathspec:

git stash push -m "Archivos nuevos" new_file.txt new_file_2.txt

Esto guarda en el stash solo new_file.txt y new_file_2.txt. El resto se queda en tu directorio de trabajo.

También puedes usar comodines:

git stash push -m "Stash de todos los .txt" *.txt

O usar --patch para un stash interactivo:

git stash push --patch

Git recorre cada cambio y te pregunta si quieres guardarlo. Respondes y (sí), n (no) o s (divide este bloque en partes más pequeñas).

Es útil cuando tienes cambios relacionados y no relacionados mezclados en el mismo archivo. Guardas en el stash el trabajo de la feature y dejas atrás el código de depuración.

Así se ve el prompt interactivo:

Listar y examinar stashes

Como ya viste, puedes ejecutar git stash list para ver todo lo que has guardado:

El stash más reciente es siempre stash@{0}. Los más antiguos bajan en el índice.

Si escribiste buenos mensajes, podrás escanear esta lista y saber qué hay en cada stash. Si no, tendrás que inspeccionarlos uno por uno.

Usa git stash show para ver un resumen:

Muestra qué archivos cambiaron y cuántas líneas se añadieron o eliminaron.

También puedes usar git stash show -p para ver el diff completo:

La bandera -p te muestra los cambios de código reales, igual que git diff. Así confirmas que vas a hacer pop del stash correcto antes de ejecutar git stash pop.

Qué hace realmente Git stash pop

Ahora veamos qué hace exactamente git stash pop y por qué lo usarías.

Comportamiento y sintaxis básicos

El comando git stash pop hace dos cosas: aplica tus cambios guardados y luego elimina ese stash de la pila.

La sintaxis básica es:

git stash pop

Esto hace pop del stash más reciente (stash@{0}) y lo quita de tu lista.

También puedes hacer pop de un stash concreto referenciando su índice:

git stash pop stash@{1}

Esto aplica stash@{1} y lo elimina, pero ojo: los stashes restantes suben de posición. Lo que era stash@{2} pasa a ser stash@{1}, y así sucesivamente.

Cómo procesa Git un stash pop

Cuando ejecutas git stash pop, Git realiza por detrás un merge a tres bandas.

Compara tres estados:

1. El commit base (donde creaste el stash)
2. Tu commit HEAD actual
3. Los cambios del stash

Si la fusión se resuelve sin conflictos, Git aplica los cambios y elimina el stash. Tu directorio de trabajo queda exactamente como antes de guardar.

Ejemplo de flujo sencillo:

# Estás trabajando en una feature
echo "new feature code" >> feature.py
git stash push -m "Trabajo de feature a medias"

# Cambia a una rama nueva y haz cambios no relacionados
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Arregla bug crítico"

# Vuelve a tu otra rama
git checkout main

# Recupera tu trabajo del stash
git stash pop

Si Git no puede fusionar limpiamente, tendrás un conflicto. El stash se queda en tu pila porque el pop no se completó con éxito. Verás marcadores de conflicto en tus archivos, igual que en un merge normal.

Cuando haya conflictos, resuélvelos manualmente, añade los archivos solucionados al staging y haz commit. El stash no desaparece automáticamente, así que tendrás que ejecutar git stash drop cuando acabes.

Aplicar stashes entre ramas

Los stashes no están ligados a una rama concreta.

Puedes crear un stash en bugfix, cambiar a main y hacer pop allí. A Git no le importa de dónde venga: solo intenta aplicar los cambios en la rama en la que estás.

Esto habilita flujos muy útiles:

1. Mover trabajo entre ramas: empezaste a programar en la rama equivocada. En lugar de hacer reset y perder trabajo, lo guardas en el stash, cambias a la rama correcta y lo aplicas allí.

2. Reorganizar tareas: guardaste código experimental hace una semana. Ahora quieres probarlo en otra rama para ver si encaja mejor allí.

3. Probar cambios en contextos distintos: tienes un arreglo de bug en el stash y quieres testearlo en varias ramas antes de hacer commit. Usa git stash apply en lugar de pop para mantener el stash, probarlo en distintas ramas y luego hacer pop en la rama donde vayas a hacer commit. Más sobre apply en un momento.

Mientras los cambios no entren en conflicto con tu rama actual, el stash se aplica limpio: esa es la idea clave a recordar.

Git stash pop vs git stash apply

A menudo surge la duda de si usar git stash pop o git stash apply.

La diferencia clave: la persistencia del stash

La principal diferencia es sencilla: pop elimina el stash tras aplicarlo, mientras que apply lo mantiene en tu pila.

Con pop dices "ya he terminado con este stash: aplícalo y deshazte de él". Con apply dices "puede que lo necesite más tarde".

Esto afecta a tu flujo de dos formas:

1. Seguridad: si algo sale mal durante un pop y necesitas recuperarte, el stash ya no está. Con apply el stash se queda en tu pila como copia de seguridad.

2. Limpieza: usar pop mantiene tu lista de stashes limpia automáticamente. Con apply tendrás que ejecutar git stash drop más tarde para eliminar los stashes que ya no necesites.

La mayoría se decanta por pop porque es más limpio. Pero apply es mejor cuando no estás seguro de que el stash vaya a encajar en tu rama actual, o cuando quieres probar los mismos cambios en varias ramas.

Predictibilidad, riesgo y cambio de índices

Aquí está lo delicado de pop: los índices cambian si haces pop desde el medio de la pila.

Imagina que tienes tres stashes:

stash@{0}: Feature en curso
stash@{1}: Arreglo de bug
stash@{2}: Código experimental

Si haces pop de stash@{1}, los restantes suben:

stash@{0}: Feature en curso
stash@{1}: Código experimental

Esto puede dar problemas si estás escribiendo scripts de Git o ejecutando varios pop en secuencia. Haces pop de stash@{1} y luego intentas hacer pop de stash@{2}, pero ese índice ya no existe.

Con apply no pasa. Los índices solo cambian cuando ejecutas explícitamente git stash drop. Puedes aplicar stashes en cualquier orden sin preocuparte de que la pila cambie por debajo.

Manejo de conflictos idéntico

Ambos comandos gestionan los conflictos exactamente igual.

Si Git no puede fusionar tus cambios del stash limpiamente, verás marcadores de conflicto. La diferencia está en qué pasa con el stash:

1. Con pop: el stash permanece en tu pila porque el pop no terminó con éxito

2. Con apply: el stash se queda en la pila (como iba a hacer igualmente)

En ambos casos, tienes que solucionar los conflictos a mano, añadir los archivos resueltos con git add y eliminar el stash con git stash drop (si usaste apply).

El flujo de resolución es idéntico: la única diferencia es si el stash se eliminaría automáticamente si todo hubiera ido bien.

Cuándo elegir cada uno

Usa git stash pop cuando:

1. Vas a aplicar un stash una sola vez y ya no lo necesitas
2. Quieres mantener limpia tu lista automáticamente
3. Trabajas en una única rama y no necesitas el stash en otras

Usa git stash apply cuando:

1. Quieres probar los mismos cambios en varias ramas
2. No estás seguro de que el stash vaya a aplicarse limpio
3. Estás automatizando con scripts y necesitas índices predecibles
4. Quieres una red de seguridad por si algo falla

Gestionar conflictos al hacer stash pop

Los conflictos ocurren cuando Git no puede fusionar limpiamente tus cambios del stash. En esta sección te muestro cómo abordarlos.

Cuándo y por qué ocurren

Un conflicto aparece durante el merge a tres bandas que hace Git al aplicar el stash.

Git compara tres versiones de tu código:

1. El commit base en el que creaste el stash
2. Tu commit HEAD actual
3. Los cambios del stash

Si las mismas líneas cambiaron tanto en tu rama actual como en el stash, Git no sabe cuál mantener. Eso es un conflicto.

Causas comunes de conflictos al hacer stash pop:

1. Modificaste el mismo archivo en ambas ramas: guardaste cambios en un archivo, cambiaste de rama y luego editaste ese archivo antes de aplicar el stash
2. Alguien más subió cambios: guardaste trabajo, hiciste pull del remoto y esas actualizaciones tocaron el mismo código
3. Hiciste rebase o cherry-pick: el commit base que espera Git ya no existe, lo que provoca desajustes al fusionar

Cuanto más tiempo dejes un stash sin aplicar, más probable será que aparezcan conflictos al final.

Flujo de resolución de conflictos

Cuando ocurre un conflicto, Git pausa el pop y marca los conflictos en tus archivos:

Tu archivo ahora contiene marcadores de conflicto:

Todo lo que hay entre <<<<<<< Updated upstream y ======= es tu código actual. Todo lo que hay entre ======= y >>>>>>> Stashed changes viene del stash.

Para arreglarlo:

1. Abre el archivo en conflicto y decide qué versión mantener (o combina ambas)

2. Elimina los marcadores de conflicto (<<<<<<<, =======, >>>>>>>)

3. Añade el archivo resuelto con git add

4. Elimina el stash manualmente con git stash drop: recuerda que no desaparece solo.

Estrategias alternativas

Si no quieres lidiar con conflictos en tu rama actual, usa git stash branch.

Este comando crea una rama nueva desde el commit en el que hiciste el stash y aplica el stash allí:

git stash branch temp-feature

Git crea una rama llamada temp-feature, hace checkout y aplica tu stash sobre ella. Como la rama parte del commit exacto donde guardaste, no habrá conflictos. Lo veremos en más detalle en otra sección.

También puedes abortar un pop fallido con git reset --merge:

git stash pop

# Aparecen conflictos

git reset --merge

Esto deshace el intento de pop y revierte tu directorio de trabajo a su estado anterior. El stash sigue en tu pila.

Abortar operaciones de stash en curso

Si empezaste un pop o apply y quieres deshacerte por completo, tienes opciones.

Para conflictos que aún no has empezado a resolver, ejecuta:

git reset --merge

Cancela el merge y limpia tu directorio de trabajo. Todo vuelve al estado previo al comando de stash.

Para conflictos que has resuelto parcialmente, ejecuta:

git reset --hard HEAD

Esto descarta todos los cambios de tu directorio de trabajo, incluidas las correcciones que hubieras hecho. Úsalo cuando todo esté hecho un lío y quieras empezar de cero.

Recuerda que este comando destruye trabajo sin confirmar. Asegúrate de que realmente quieres tirarlo todo antes de ejecutarlo.

Tras abortar, tu stash sigue en la pila (salvo que usaras pop y hubiera terminado antes de los conflictos). Puedes intentarlo de nuevo más tarde o usar git stash branch para un enfoque más limpio.

Limpiar tus stashes

En proyectos largos, los stashes se acumulan rápido. Guardas trabajo para arreglar un bug y te olvidas. Creas stashes experimentales que nunca aplicas. Seis meses después, tienes 20 y no recuerdas qué hay en la mitad.

Esto complica encontrar el que de verdad necesitas. Acabas ejecutando git stash show -p en cada uno para ver qué contienen.

Es una gran pérdida de tiempo, así que acuérdate de limpiar tus stashes con regularidad.

Eliminar stashes individuales

Usa git stash drop para quitar un stash concreto:

git stash drop stash@{2}

Esto elimina stash@{2} de tu pila. Los restantes suben: lo que era stash@{3} pasa a ser stash@{2}.

También puedes eliminar el más reciente sin especificar índice:

git stash drop

Esto quita stash@{0} por defecto.

Tras años trabajando con Git, estas son mis razones principales para eliminar stashes:

1. Te das cuenta de que ya no necesitas esos cambios
2. Tienes stashes duplicados (pasa más de lo que crees)
3. Un stash es tan antiguo que ya no recuerdas para qué era

Si no tienes claro si eliminarlo, usa git stash show -p para inspeccionarlo antes. Mejor prevenir que curar.

Vaciar toda la pila de stashes

Puedes usar git stash clear para borrar todos los stashes de golpe:

git stash clear

Recuerda que es permanente. No puedes deshacerlo ni recuperar los stashes después.

Usa git stash clear solo cuando tengas clarísimo que no necesitas nada de lo guardado.

La mayoría de las veces, es mejor eliminarlos uno a uno para no borrar por accidente algo que sí necesitas.

Crear ramas a partir de stashes

A veces, la solución más limpia es convertir un stash en su propia rama. Evitas conflictos y le das a tu trabajo guardado un hogar adecuado.

Usar git stash branch

El comando git stash branch crea una rama nueva y aplica tu stash en ella:

Esto es lo que ocurre:

1. Git crea una rama nueva llamada feature-experiment desde el commit en el que hiciste el stash

2. Git hace checkout de esa rama nueva

3. Git aplica el stash en la rama

4. Git elimina el stash de tu pila (igual que con pop)

Como la rama parte del mismo commit que el stash, no habrá conflictos. Los cambios se aplican siempre de forma limpia.

También puedes usar un stash específico en vez del más reciente:

git stash branch new-feature stash@{2}

Casos de uso habituales

Crear una rama desde un stash es perfecto para features experimentales. Imagina que guardaste código experimental hace una semana y ahora quieres desarrollarlo en condiciones sin fastidiar tu trabajo actual.

Obtienes una rama limpia para trabajar en el experimento. Si sale bien, haces merge. Si no, borras la rama y listo.

También viene genial para rebases largos. En lugar de lidiar con conflictos potenciales durante el rebase, haces stash de todo y creas una rama a partir de él.

git stash push -m "WIP antes del rebase"
git rebase main
git stash branch temp-work

Ahora puedes revisar los cambios guardados por separado y decidir cómo integrarlos después del rebase.

Crear una rama también ayuda a aislar cambios grandes o desordenados. Imagina un stash enorme con cambios en 15 archivos, la mitad en conflicto con tu rama actual. Crea una rama nueva y evita pelearte con ellos.

Tendrás una rama dedicada donde revisar todo con calma, hacer commits en condiciones y luego fusionar con un historial claro.

Técnicas avanzadas y opciones de recuperación

A estas alturas ya dominas lo básico de git stash, así que veamos conceptos más avanzados.

Trabajar con entradas de stash específicas

Puedes aplicar o hacer pop de cualquier stash, no solo del más reciente.

Referencia los stashes por su índice para coger exactamente el que necesitas:

git stash pop stash@{3}
git stash apply stash@{1}

Así puedes recuperar stashes antiguos sin tocar los nuevos. Cuando haces pop de un stash intermedio, todos los índices por debajo suben. Lo que era stash@{4} pasa a ser stash@{3}, etc. Si estás scriptando Git o encadenando pops, este cambio de índices romperá tus comandos.

La solución es usar apply en lugar de pop cuando necesites índices predecibles:

git stash apply stash@{2}

# Elimínalo manualmente cuando termines
git stash drop stash@{2}

Así controlas exactamente cuándo cambia la pila. Aplicas el stash, verificas que todo está bien y entonces lo eliminas tú. Los índices solo se mueven cuando tú lo indicas.

Restaurar el estado del staging

Por defecto, git stash pop y git stash apply restauran tus cambios pero no preservan qué estaba en staging.

Imagina que tenías tres archivos modificados, y antes de hacer stash dejaste dos en staging. Al aplicar el stash, los tres vuelven como cambios sin preparar. Git pierde qué archivos querías incluir en el commit.

La solución es usar la bandera --index para restaurar el estado del staging tal cual estaba:

git stash pop --index

Esto recrea tu árbol de trabajo y el índice exactamente como antes del stash. Los archivos que estaban en staging siguen en staging. Los que no, se quedan fuera. Todo vuelve justo donde estaba.

Necesitarás esta bandera cuando:

1. Estás preparando un commit muy medido y no puedes permitirte perder esa selección

2. Trabajas con escenarios complejos de staging, por ejemplo usando git add -p para preparar solo bloques concretos

3. Quieres que tu directorio de trabajo quede exactamente como antes del stash, sin excepciones

La mayoría de las veces no la necesitarás. Harás pop, verás qué ha vuelto y pondrás en staging lo que toque.

Recuperarte de errores con el stash

Tarde o temprano eliminarás un stash que necesitabas o vaciarás tu pila sin querer.

Si te pasa, el reflog de Git puede salvarte el día.

El reflog registra cada cambio de referencia en tu repositorio, incluidos los stashes. Cuando creas o eliminas uno, Git lo anota en el reflog. Incluso después de eliminarlo, los commits siguen existiendo un tiempo como objetos inalcanzables.

Puedes encontrar tu stash perdido buscando commits inalcanzables:

git fsck --unreachable | grep commit

Ahora inspecciona cada commit para encontrar tu stash:

git show 066ded985342e585bc8e75c074add99ec1950f50

Mira el diff y el mensaje para identificar cuál es tu stash perdido. Cuando lo encuentres, recupéralo:

git stash apply 066ded985342e585bc8e75c074add99ec1950f50

Esto aplica el stash perdido a tu directorio de trabajo como si nunca lo hubieras eliminado.

Mejor aún, evita errores desde el principio con estas buenas prácticas:

1. Escribe mensajes descriptivos para cada stash. "Arreglo bug de login" supera a "WIP" cuando miras una lista con cinco stashes.

2. Usa git stash show -p antes de eliminar para confirmar que es el correcto. Mejor dedicar cinco segundos a verificar que cinco minutos a recuperar.

3. Limpia tu pila con regularidad para que no se vuelva inmanejable. Tres stashes relevantes se navegan mejor que 15 entradas antiguas.

4. Usa apply en lugar de pop cuando no tengas 100% claro que quieres borrar el stash. Siempre puedes eliminarlo después de verificar que todo funciona.

La recuperación con reflog funciona, pero es tediosa. Solo mira la imagen de arriba para ver cuántos commits tendría que revisar a mano —y esto es un proyecto pequeño creado solo para este artículo.

Mejores prácticas y pautas de trabajo

Usar bien los stashes implica seguir patrones que evitan errores y mantienen tu flujo limpio. Te cuento mi enfoque de referencia.

Patrones de flujo recomendados

El flujo más seguro es sencillo: guarda con mensaje, cambia de contexto y haz pop cuando estés listo para seguir.

# Trabaja en feature-branch
git stash push -m "Feature en curso"

git checkout main
# Trabajo urgente en main

# Vuelve
git checkout feature-branch
git stash pop

Funciona en la mayoría de situaciones. Conservas tu trabajo, atiendes la interrupción y lo restauras sin problemas.

Otro patrón común es el de "inspeccionar antes de aplicar". Listas tus stashes, examinas qué hay, y luego haces pop del que toca.

git stash list
git stash show -p stash@{1}
git stash pop stash@{1}

Este paso extra evita que apliques el stash equivocado o trabajo desfasado.

Algunos prefieren la alternativa del "commit reacio" frente al stash. En lugar de guardar, hacen un commit temporal con mensaje tipo "WIP - no listo" y luego lo corrigen o resetean. Funciona si no te sientes cómodo con los stashes o si quieres que el trabajo quede en el historial de la rama. La pega es que puedes ensuciar el log si olvidas limpiarlo.

Integración con tus herramientas

La mayoría de GUIs de Git muestran tus stashes y te permiten aplicarlos con un clic.

Herramientas como GitKraken, Sourcetree y GitHub Desktop listan tus stashes en una barra lateral. Ves el mensaje, inspeccionas el diff y aplicas o eliminas sin teclear comandos. Es útil cuando tienes varios y quieres compararlos en paralelo.

La extensión de Git de VS Code muestra los stashes en el panel de control de código fuente. Puedes hacer clic derecho para aplicar, hacer pop o eliminar sin salir del editor.

Si prefieres la terminal, crea alias para ir más rápido. Añade esto a tu .bashrc o .zshrc:

alias gst='git stash'
alias gstp='git stash pop'
alias gstl='git stash list'
alias gsts='git stash show -p'

Ahora gst guarda tu trabajo, gstp lo aplica, gstl lista tus stashes y gsts muestra el diff. Ahorras unas cuantas teclas cada vez.

Higiene del stash y trabajo en equipo

Los stashes son locales a tu máquina: nunca se suben a remotos.

Esto significa que tus compañeros no pueden verlos y tú no puedes acceder a ellos desde otro equipo. Si necesitas compartir trabajo en curso, no lo guardes en un stash. Usa parches o ramas temporales.

Para compartir mediante parches, ejecuta lo siguiente:

git stash show -p > my-work.patch
# Envía el archivo patch a tu compañero
# Lo aplicará con: git apply my-work.patch

Ahora envía el archivo a tu compañero y lo aplicará con git apply my-work.patch.

Para compartir mediante ramas temporales, ejecuta esto:

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - feature de autenticación"
git push origin temp/work-in-progress

Tu compañero puede traer la rama, revisar el trabajo y continuar desde ahí.

Elijas lo que elijas, mantén una buena higiene del stash. Evitará confusiones y mantendrá tu pila controlada. Algunas buenas prácticas:

1. Usa nombres descriptivos para cada stash. "Añadir lógica de autenticación" te cuenta qué hay dentro. "WIP on feature-branch" no.

2. Limpia tus stashes cada semana. Ejecuta git stash list y elimina todo lo anterior a una semana. Si no lo has necesitado en siete días, probablemente no lo necesitarás.

3. No dejes que tu cuenta de stashes supere cinco. Más de cinco suele significar que los usas como almacenamiento a largo plazo, no como un aparcamiento temporal. O aplícalos, o haz commit, o elimínalos.

4. Si trabajas en equipo y alguien pregunta "¿Dónde está ese código en el que estabas?", nunca respondas "En mi stash". Los stashes son privados y temporales: no sirven para compartir ni archivar trabajo importante.

Conclusión

Ahora ya sabes cómo funciona git stash pop y cuándo usarlo.

En esencia, el stash es simple: guarda tu trabajo sin confirmar, cambia de contexto y restáuralo después. Pero los detalles importan. Saber cuándo usar pop frente a apply, cómo gestionar conflictos y cuándo crear ramas desde stashes te ahorrará horas de frustración.

La idea más importante: los stashes son almacenamiento temporal, no copias de seguridad permanentes. Usa mensajes descriptivos, limpia con regularidad y no dejes que tu pila supere cinco entradas. Si necesitas compartir trabajo o mantenerlo a largo plazo, súbelo a una rama.

Si te ha gustado este artículo y quieres mejorar con Git, tus próximas paradas son nuestros cursos Intermediate Git y Intermediate GitHub Concepts.