■ space · carril de prosa

■ la respuesta primero

git stash push -m "why" -- <path> aparca exactamente el archivo nombrado; todos los demás archivos sucios jamás se mueven.

Un solo archivo fuera de cualquier stash: git restore --source stash@{0} -- <path> — la entrada se queda.

La forma pathspec existe desde git 2.13 (mayo de 2017); los archivos sin seguimiento necesitan -u.

LA DIVISIÓN

Tres archivos sucios, uno debe moverse. Mira dividirse el árbol — un archivo al stash, dos jamás se mueven:

ANTES · git status --short

 M app.conf   ← must move
 M notes.md
 M main.py

DESPUÉS

 M notes.md   ← never moved
 M main.py    ← never moved

stash@{0}: On main: app.conf prod tweak

app.conf vuelve a su estado commitado y se sienta en stash@{0} — el mensaje -m se gana sus tres segundos en cuanto git stash list tiene más de una entrada; nombres como «WIP» envejecen mal

EL PATHSPEC ES TODO EL TRUCO

Un git stash barre el árbol de trabajo entero — toda modificación seguida entra, todo vuelve a HEAD. Forma incorrecta cuando el árbol sucio es mixto: un archivo listo para entregar, el resto genuinamente inacabado. Dos detalles que valen saber:

El pathspec va después de --. Todo lo que sigue del doble guion son rutas, no banderas — la misma convención que git checkout -- <path>, y no es decorativa: versiones viejas de git podían malinterpretar una ruta desnuda.
Los archivos sin seguimiento necesitan -u. Un archivo recién nacido no tiene historial seguido que stashear, así que un push pelado lo salta. git stash push -u -- newfile.py lo incluye; -a va más lejos y barre también los archivos ignorados.

MEDIO ARCHIVO: LA DIVISIÓN INTERACTIVA

Cuando el propio archivo está a medio terminar — tres hunks buenos, uno vergonzoso — git stash -p (o git stash push -p) recorre cada hunk y pregunta Stash this hunk [y,n,q,a,d,j,g,/,e,p,?]?. Responde y para los hunks que van al stash, n para los que se quedan; el resultado es un stash que contiene solo lo que aprobaste. La misma maquinaria hunk a hunk mueve git add -p, así que el reflejo se transfiere. Las dos granularidades, lado a lado:

	`git stash push -- <path>`	`git stash -p`
Granularidad	archivos enteros	hunks individuales
Velocidad	un comando, scriptable	interactivo, hunk por hunk
Repetible en CI	sí (rutas como argumentos)	no — necesita un humano en el prompt
Mejor para	«este archivo, no el resto»	«este cambio, no ese otro»
Desde	git 2.13 (mayo de 2017)	disponible desde hace mucho

Regla del pulgar desde el propio modelo de la doc: pathspec cuando la frontera es el archivo, -p cuando la frontera está dentro.

UN ARCHIVO FUERA

git stash pop restaura stash@{0} y borra la entrada — el camino normal, pero pop es todo-o-nada por stash, y un conflicto aborta el pop conservando la entrada. Dos opciones más finas:

# 1. apply without dropping (safe re-run)
git stash apply stash@{0}

# 2. pull ONE file out of a stash, leave the entry intact
git restore --source stash@{0} -- app.conf
# pre-2.23 spelling of the same operation:
git checkout stash@{0} -- app.conf

verificación: git stash list tras el restore → stash@{0} sigue en pie — solo pop borra la entrada

CUANDO EL STASH ES LA HERRAMIENTA EQUIVOCADA

El stash es un borrador, no una rama. Los stashes viven solo en tu máquina, no llevan mensaje más allá de la línea única, y son famosos por lo fácil que se olvidan — git stash list es un género por derecho propio.git switch -c wip-labels El trabajo que debe sobrevivir días, viajar entre máquinas, o llevar un mensaje de commit real, pertenece a una rama:

■ sello honesto Probado en: git 2.13+ pathspec · git 2.23+ restore · todas las mayores. Primera publicación 2026-09-21. La forma pathspec, la bandera -u para rutas sin seguimiento, el prompt de hunk y la grafía restore-desde-stash son el comportamiento de stash documentado de git — la salida status antes/después de arriba es exactamente lo que imprime la secuencia.

fin del archivo único · nada fetchado · todo local