Git Stash Pop: conserva il lavoro quando cambi branch

Se hai del lavoro a metà che non è pronto per un commit ma devi cambiare contesto subito, non fare un commit "WIP". E non fare nemmeno copia-incolla delle modifiche in un file di testo come se fossimo nel 2005. git stash è tutto ciò di cui hai bisogno.

Questo comando è il modo migliore per conservare il lavoro non committato mentre cambi contesto. Ti permette di salvare temporaneamente le modifiche, gestire attività urgenti su altri branch e ripristinare tutto esattamente dove l'avevi lasciato.

In questo articolo ti mostrerò come funziona git stash pop, quando usarlo al posto di git stash apply e come recuperare la situazione quando, inevitabilmente, compaiono conflitti.

Se sei alle prime armi con Git e trovi confuso il concetto di stash, assicurati prima di padroneggiare le basi. I nostri corsi Introduction to Git e Introduction to GitHub ti metteranno in carreggiata in pochissimo tempo.

Capire Git Stash

Git stash è il tuo archivio temporaneo per le modifiche non committate.

Pensalo come una clipboard per il tuo lavoro. Hai delle modifiche nella working directory che non sono pronte per il commit, ma devi cambiare branch o fare pull dal remoto. Invece di perdere il lavoro o fare un commit WIP, lo metti nello stash.

Il comando salva le tue modifiche e ripristina la working directory in modo che corrisponda al commit HEAD.

L'idea dello stash in Git

Lo stash risolve un problema semplice: Git non ti permette di cambiare branch con modifiche non committate.

Mettiamo che tu stia lavorando a una feature quando arriva una segnalazione di bug. Devi passare subito a un altro branch, ma hai codice a metà e file modificati. Un commit non ha senso perché il lavoro è incompleto. Un checkout forzato farebbe perdere le modifiche.

È lì che usi lo stash.

Ecco gli scenari più comuni in cui lo stash può aiutarti:

1. Cambiare branch per lavoro urgente: sei a metà di una feature quando devi correggere un bug in produzione.
2. Fare pull dal remoto: un collega ha pushato aggiornamenti e devi fare pull, ma hai modifiche locali.
3. Evitare commit disordinati: non sei pronto per il commit, ma vuoi una working directory pulita per un rebase o un merge.
4. Salvare codice sperimentale: vuoi provare un approccio diverso senza perdere il lavoro attuale

Lo stash è rapido e reversibile: niente messaggi di commit o nomi di branch a cui pensare.

L'architettura dello stack di stash

Git gestisce gli stash in uno stack LIFO (last-in, first-out).

Ogni volta che fai uno stash, Git crea una nuova voce in cima allo stack. Lo stash più recente diventa stash@{0} e quelli più vecchi scalano: stash@{1}, stash@{2} e così via.

Dietro le quinte, ogni stash è in realtà un commit — o, più precisamente, un insieme di commit. Git crea una struttura di commit multi-genitore che memorizza:

1. Le modifiche nella tua working directory
2. Le modifiche in stage (l'index)
3. I file non tracciati (se hai usato il flag u)

Questa struttura significa che gli stash non sono solo snapshot. Sono veri commit che Git può unire di nuovo nella tua working directory in seguito.

Puoi fare riferimento agli stash in due modi: per indice usando la sintassi stash@{0}, oppure usando git stash list per trovare il messaggio che hai dato e riferirti a quello specifico stash. L'indice è più veloce per gli stash recenti, ma i messaggi sono migliori quando ne hai salvati molti.

Ecco come appare tipicamente uno stack di stash:

Il prefisso WIP on significa che hai usato git stash senza messaggio. Il prefisso On indica che hai fornito un messaggio personalizzato con git stash push -m.

Gli stash vivono solo nel tuo repository locale: non vengono pushati sul remoto. Questo mantiene il tuo lavoro temporaneo esattamente dove deve stare: sulla tua macchina, pronto da ripristinare quando serve.

Creare, gestire ed esaminare gli stash

Il comando base git stash basta per iniziare, ma è pigro. Finirai con una pila di voci "WIP on branch-name" che non ti dicono nulla su cosa contengono. Sei settimane dopo, non ricorderai più quale stash contiene la correzione del bug e quale il refactoring a metà.

Ora ti mostro come farlo bene fin dall'inizio.

Creare stash con metadati adeguati

Il modo più semplice per fare uno stash è digitare git stash:

git stashOfferto da

Questo salva le modifiche, ma il messaggio "WIP on main" non è molto informativo. Non puoi sapere cosa c'è dentro senza ispezionarlo.

Al contrario, esegui git stash push -m con un messaggio descrittivo:

git stash push -m "Updated file.txt"Offerto da

Ora la tua lista di stash è davvero informativa:

La differenza è evidente. Una voce ti dice esattamente cosa hai fatto, l'altra ti costringe a indovinare.

Scrivi i messaggi come se stessi lasciando note al tuo te futuro. "Aggiunta logica di auth", "Fix bug navbar" o "Esperimento con nuovo design API" battono sempre i generici messaggi WIP.

Includere file non tracciati o ignorati

Per impostazione predefinita, git stash salva solo i file tracciati — quelli che Git già conosce.

I file non tracciati rimangono nella working directory. Questo sorprende quando si fa stash, si cambia branch e si vedono ancora i file nuovi lì.

Ecco cosa succede:

echo "new_feature.py" > new_feature.py
git stashOfferto da

Il file non è finito nello stash perché Git non lo traccia ancora:

Per ovviare, usa il flag -u per includere i file non tracciati nello stash:

git stash push -u -m "Added a Python file for a new cool feature"Offerto da

Questo mette in stash sia i file tracciati che quelli non tracciati. La tua working directory risulta completamente pulita.

Suggerimento: puoi aggiungere il flag -a per includere anche i file ignorati. Mette in stash i file tracciati, non tracciati e quelli presenti nel tuo .gitignore. Ti serve raramente, a meno che tu non stia facendo debug di problemi di build o voglia salvare uno snapshot completamente pulito di tutto.

Ecco un promemoria per sapere quando usare ciascun flag:

1. Nessun flag: hai modificato solo file esistenti

2. u flag: hai aggiunto nuovi file non ancora tracciati

3. a flag: devi salvare tutto, inclusi output di build o file temporanei

La maggior parte delle volte userai -u. È l'opzione più sicura quando hai creato nuovi file durante lo sviluppo.

Stash parziale o selettivo

Non devi per forza mettere in stash tutto ciò che c'è nella tua working directory.

Mettiamo che tu abbia corretto due bug, ma voglia mettere in stash solo uno di essi. O hai modifiche su cinque file, ma solo tre sono legati alla feature che vuoi salvare.

Puoi mettere in stash file specifici con pathspec:

git stash push -m "New files" new_file.txt new_file_2.txtOfferto da

Questo mette in stash solo new_file.txt e new_file_2.txt. Tutto il resto rimane nella working directory.

Puoi anche usare i wildcard:

git stash push -m "Stash all txt files" *.txtOfferto da

Oppure puoi usare --patch per uno stash interattivo:

git stash push --patchOfferto da

Git passa in rassegna ogni modifica e ti chiede se vuoi metterla in stash. Rispondi y (yes), n (no) o s (split — dividi questa hunk in parti più piccole).

È utile quando hai modifiche correlate e non correlate mischiate nello stesso file. Metti in stash il lavoro sulla feature e lasci indietro il codice di debug.

Ecco come appare il prompt interattivo:

Elencare ed esaminare gli stash

Come hai già visto, puoi eseguire git stash list per vedere tutto ciò che hai messo nello stash:

Lo stash più recente è sempre stash@{0}. Gli stash più vecchi scalano nell'indice.

Se hai scritto buoni messaggi, puoi scorrere la lista e sapere esattamente cosa c'è in ogni stash. Se non l'hai fatto, dovrai ispezionarli uno per uno.

Usa git stash show per vedere un riepilogo:

Mostra quali file sono cambiati e quante righe sono state aggiunte o rimosse.

In alternativa, usa git stash show -p per vedere l'intero diff:

Il flag -p ti mostra le effettive modifiche al codice, proprio come git diff. Così puoi confermare di stare per fare pop dello stash giusto prima di eseguire git stash pop.

Cosa fa davvero Git Stash Pop

Parliamo ora di cosa fa effettivamente git stash pop e perché lo useresti.

Comportamento fondamentale e sintassi

Il comando git stash pop fa due cose: applica le modifiche stivate e poi elimina quello stash dallo stack.

Ecco la sintassi di base:

git stash popOfferto da

Questo fa pop dello stash più recente (stash@{0}) e lo rimuove dalla lista degli stash.

Puoi anche fare pop di uno stash specifico riferendoti al suo indice:

git stash pop stash@{1}Offerto da

Questo applica stash@{1} e lo rimuove, ma c'è un dettaglio: gli stash rimanenti scalano verso l'alto. Quello che era stash@{2} diventa stash@{1}, e così via.

Come Git elabora uno stash pop

Quando esegui git stash pop, Git effettua dietro le quinte un merge a tre vie.

Confronta tre stati:

1. Il commit base (dove hai creato lo stash)
2. Il commit HEAD attuale
3. Le modifiche stivate

Se il merge riesce senza conflitti, Git applica le modifiche e rimuove lo stash. La tua working directory torna esattamente com'era prima dello stash.

Ecco un esempio di workflow semplice:

# Stai lavorando a una feature
echo "new feature code" >> feature.py
git stash push -m "Half-finished feature work"

# Passa a un nuovo branch e fai modifiche non correlate
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Fix critical bug"

# Torna all'altro branch
git checkout main

# Fai pop del lavoro stivato
git stash popOfferto da

Se Git non riesce a fare il merge pulito, ottieni un conflitto. Lo stash rimane nello stack perché il pop non è terminato con successo. Vedrai i marker di conflitto nei tuoi file, proprio come in un normale merge conflict.

Quando si verificano conflitti, devi risolverli manualmente, mettere in stage i file corretti e fare commit. Lo stash non sparisce automaticamente, quindi dovrai eseguire git stash drop dopo aver risolto tutto.

Applicare gli stash tra branch diversi

Gli stash non sono legati a uno specifico branch.

Puoi creare uno stash su bugfix, passare a main e fare pop di quello stash lì. A Git non importa da dove proviene lo stash: prova semplicemente ad applicare le modifiche al branch su cui ti trovi.

Questo abilita workflow comodi:

1. Spostare lavoro tra branch: hai iniziato a codare sul branch sbagliato. Invece di resettare e perdere il lavoro, lo metti nello stash, passi al branch corretto e fai pop lì.

2. Riorganizzare le attività: hai messo in stash del codice sperimentale una settimana fa. Ora vuoi provarlo su un branch diverso per vedere se funziona meglio lì.

3. Testare modifiche in contesti diversi: hai un fix messo in stash e vuoi testarlo su più branch prima di fare commit. Usa git stash apply invece di pop per mantenere lo stash, testarlo su branch diversi, quindi pop nel branch in cui vuoi fare commit. Tra poco parliamo meglio di apply.

Finché le modifiche non vanno in conflitto con il branch attuale, lo stash si applica senza problemi: è questa l'idea principale da ricordare.

Git Stash Pop vs Git Stash Apply

Spesso ci si chiede se usare git stash pop o git stash apply.

La differenza chiave: persistenza dello stash

La principale differenza è semplice: pop rimuove lo stash dopo averlo applicato, mentre apply lo mantiene nello stack.

Con pop stai dicendo "Ho finito con questo stash: applicalo e buttalo". Con apply stai dicendo "Potrei averne bisogno di nuovo più tardi".

Questo influisce sul flusso di lavoro in due modi:

1. Sicurezza: se qualcosa va storto durante un pop e devi recuperare, lo stash è sparito. Con apply lo stash rimane nello stack come backup.

2. Pulizia: usare pop mantiene automaticamente la lista degli stash pulita. Usare apply significa dover eseguire manualmente git stash drop più tardi per rimuovere gli stash che hai finito di usare.

La maggior parte degli sviluppatori usa di default pop perché è più pulito. Ma apply è migliore quando non sei sicuro che lo stash funzioni sul branch attuale o quando vuoi testare le stesse modifiche su più branch.

Predicibilità, rischio e shift degli indici

Ecco dove pop si complica: gli indici degli stash si spostano quando fai pop dal centro dello stack.

Mettiamo che tu abbia tre stash:

stash@{0}: Feature work
stash@{1}: Bug fix
stash@{2}: Experimental codeOfferto da

Se fai pop di stash@{1}, gli stash rimanenti scalano verso l'alto:

stash@{0}: Feature work
stash@{1}: Experimental codeOfferto da

Questo può creare problemi se stai scriptando operazioni Git o eseguendo in sequenza più comandi di pop. Fai pop di stash@{1}, poi provi a fare pop di stash@{2}, ma quell'indice non esiste più.

Il comando apply non ha questo problema. Gli indici si spostano solo quando esegui esplicitamente git stash drop. Puoi applicare gli stash in qualsiasi ordine senza preoccuparti che lo stack cambi sotto di te.

Gestione dei conflitti identica

Entrambi i comandi gestiscono i conflitti nello stesso identico modo.

Se Git non riesce a fare il merge pulito delle modifiche stivate, vedrai i marker di conflitto nei file. La differenza sta in cosa succede allo stash:

1. Con pop: lo stash rimane nello stack perché il pop non è andato a buon fine

2. Con apply: lo stash rimane nello stack (come sarebbe comunque)

In entrambi i casi devi risolvere i conflitti manualmente, mettere in stage i file risolti con git add e rimuovere lo stash con git stash drop (se usi apply).

Il workflow di risoluzione dei conflitti è identico: l'unica differenza è se lo stash sarebbe stato rimosso automaticamente in caso di successo.

Quando scegliere l'uno o l'altro

Usa git stash pop quando:

1. Applichi uno stash una volta sola e hai finito
2. Vuoi mantenere automaticamente pulita la lista degli stash
3. Lavori su un solo branch e non ti serve lo stash altrove

Usa git stash apply quando:

1. Vuoi testare le stesse modifiche su più branch
2. Non sei sicuro che lo stash si applichi pulito
3. Stai scriptando operazioni Git e ti servono indici predicibili
4. Vuoi una rete di sicurezza in caso succeda qualcosa

Gestire i conflitti nei pop dello stash

I conflitti capitano quando Git non riesce a fare un merge pulito delle modifiche stivate. In questa sezione ti mostrerò come gestirli.

Quando si verificano conflitti e perché

Un conflitto avviene durante il merge a tre vie che Git esegue quando fai pop di uno stash.

Git confronta tre versioni del tuo codice:

1. Il commit base in cui hai creato lo stash
2. Il commit HEAD attuale
3. Le modifiche stivate

Se le stesse righe sono cambiate sia nel branch attuale che nello stash, Git non sa quale versione tenere. Questo è un conflitto.

Cause comuni di conflitti con stash pop:

1. Hai modificato lo stesso file su entrambi i branch: hai messo in stash modifiche a un file, sei passato a un altro branch e poi hai modificato di nuovo lo stesso file prima del pop
2. Qualcun altro ha pushato modifiche: hai messo in stash, hai fatto pull dal remoto e quegli aggiornamenti hanno toccato lo stesso codice
3. Hai fatto rebase o cherry-pick di commit: il commit base che Git si aspetta non esiste più, causando discrepanze nel merge

In generale, più a lungo uno stash rimane lì, più è probabile che tu abbia conflitti quando finalmente lo fai pop.

Workflow di risoluzione dei conflitti

Quando si verifica un conflitto, Git mette in pausa il pop e marca i conflitti nei file:

Il tuo file ora contiene marker di conflitto:

Tutto ciò che è tra <<<<<<< Updated upstream e ======= è il tuo codice attuale. Tutto ciò che è tra ======= e >>>>>>> Stashed changes proviene dallo stash.

Ecco cosa puoi fare per sistemare:

1. Apri il file in conflitto e decidi quale versione tenere (o combina entrambe)

2. Rimuovi i marker di conflitto (<<<<<<<, =======, >>>>>>>)

3. Metti in stage il file risolto con git add

4. Elimina manualmente lo stash con git stash drop — ricordati che non sparirà da solo.

Strategie alternative

Se non vuoi gestire conflitti nel branch attuale, usa git stash branch.

Questo comando crea un nuovo branch dal commit in cui hai fatto lo stash, quindi applica lì lo stash:

git stash branch temp-featureOfferto da

Git crea un branch chiamato temp-feature, lo fa checkout e ci fa pop dello stash. Poiché il branch parte esattamente dal commit in cui hai fatto lo stash, non ci saranno conflitti. Ne parlerò più a fondo in una sezione separata.

Puoi anche annullare un pop fallito con git reset --merge:

git stash pop

# Compaiono conflitti

git reset --mergeOfferto da

Questo annulla il tentativo di pop e riporta la working directory allo stato precedente. Lo stash rimane nello stack.

Interrompere operazioni di stash in corso

Se hai iniziato un pop o un apply e vuoi tirarti indietro del tutto, hai delle opzioni.

Per conflitti che non hai ancora iniziato a risolvere, esegui:

git reset --mergeOfferto da

Questo annulla il merge e ripulisce la working directory. Tutto torna com'era prima del comando di stash.

Per conflitti che hai risolto in parte, esegui:

git reset --hard HEADOfferto da

Questo elimina tutte le modifiche nella working directory, incluse eventuali correzioni già fatte. Usalo quando hai fatto confusione e vuoi semplicemente ricominciare.

Ricorda che questo comando distrugge il lavoro non committato. Assicurati di voler davvero buttare via tutto prima di eseguirlo.

Dopo aver annullato, il tuo stash è ancora nello stack (a meno che tu non abbia usato pop e sia andato a buon fine prima dei conflitti). Puoi riprovare più tardi o usare git stash branch per un approccio più pulito.

Pulire gli stash

Gli stash si accumulano in fretta nei progetti di lunga durata. Metti in stash per correggere un bug e poi te ne dimentichi. Crei stash sperimentali che non fai mai pop. Sei mesi dopo, hai 20 stash e non hai idea di cosa contenga metà di essi.

Questo rende più difficile trovare lo stash che ti serve davvero. Finisci per eseguire git stash show -p su ognuno per capire cosa c'è dentro.

È una gran perdita di tempo, quindi ricordati di pulire regolarmente gli stash.

Eliminare singoli stash

Usa git stash drop per rimuovere uno stash specifico:

git stash drop stash@{2}Offerto da

Questo elimina stash@{2} dallo stack. Gli stash rimanenti scalano in alto: ciò che era stash@{3} diventa stash@{2}.

Puoi anche eliminare lo stash più recente senza specificare un indice:

git stash dropOfferto da

Questo rimuove di default stash@{0}.

In anni di lavoro con Git, i principali motivi per eliminare gli stash sono quando:

1. Ti rendi conto che le modifiche non servono più
2. Hai stash duplicati (succede più spesso di quanto pensi)
3. Uno stash è talmente vecchio che non ricordi più a cosa serviva

Se non sei sicuro se eliminare uno stash, usa git stash show -p per ispezionarlo prima. Meglio prevenire che curare.

Svuotare l'intero stack di stash

Puoi usare git stash clear per eliminare tutti gli stash in una volta:

git stash clearOfferto da

Ricorda solo che è permanente. Non puoi annullarlo né recuperare gli stash dopo.

Usa git stash clear solo quando sei assolutamente certo di non aver bisogno di nessuno dei lavori stivati.

Nella maggior parte dei casi, è meglio eliminare gli stash singolarmente per non cancellare per sbaglio qualcosa di utile.

Creare branch dagli stash

A volte la soluzione più pulita è trasformare uno stash in un branch a sé. Eviti conflitti di merge e dai al lavoro stivato una casa adeguata.

Usare git stash branch

Il comando git stash branch crea un nuovo branch e applica lo stash:

Ecco cosa succede:

1. Git crea un nuovo branch chiamato feature-experiment dal commit in cui hai fatto lo stash

2. Git fa checkout di quel nuovo branch

3. Git fa pop dello stash su quel branch

4. Git rimuove lo stash dallo stack (come con pop)

Poiché il branch parte dallo stesso commit dello stash, non ci saranno conflitti. Le modifiche si applicano pulite ogni volta.

Puoi anche usare uno stash specifico invece del più recente:

git stash branch new-feature stash@{2}Offerto da

Casi d'uso comuni

Creare un branch da uno stash è perfetto per le feature sperimentali. Mettiamo che tu abbia messo in stash del codice sperimentale una settimana fa e ora voglia svilupparlo come si deve senza incasinare il lavoro attuale.

Ottieni un branch pulito su cui lavorare all'esperimento. Se funziona, fai merge. Se non funziona, elimini il branch e avanti.

È ottimo anche per rebase lunghi. Invece di gestire potenziali conflitti durante il rebase, puoi semplicemente mettere tutto in stash e creare un branch da lì.

git stash push -m "WIP before rebase"
git rebase main
git stash branch temp-workOfferto da

Ora puoi rivedere separatamente le modifiche stivate e decidere come integrarle dopo il rebase.

Creare un branch è utile anche per isolare modifiche grandi o disordinate. Immagina uno stash enorme con cambi su 15 file, metà dei quali vanno in conflitto col branch attuale. Crea un nuovo branch: non serve combatterci sopra.

Hai un branch dedicato in cui rivedere tutto con calma, fare commit come si deve e poi fare merge con una cronologia pulita.

Tecniche avanzate e opzioni di recupero

A questo punto conosci le basi di git stash, quindi vediamo alcuni concetti più avanzati.

Lavorare con voci di stash specifiche

Puoi fare pop o apply di qualsiasi stash nello stack, non solo dell'ultimo.

Basta riferirsi agli stash per indice per prendere esattamente quello che ti serve:

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

Questo ti permette di recuperare stash vecchi senza toccare quelli nuovi. Quando fai pop di uno stash intermedio, tutti gli indici sotto si spostano verso l'alto. Ciò che era stash@{4} diventa stash@{3} e così via. Se stai scriptando operazioni Git o facendo pop in sequenza di più stash, questo spostamento degli indici romperà i tuoi comandi.

La soluzione è usare apply invece di pop quando ti servono indici predicibili:

git stash apply stash@{2}

# Eliminalo manualmente quando hai finito
git stash drop stash@{2}Offerto da

Questo ti dà il pieno controllo su quando lo stack cambia. Applichi lo stash, verifichi che abbia funzionato correttamente, poi lo elimini tu. Gli indici si spostano solo quando lo dici esplicitamente.

Ripristinare lo stato in stage

Per impostazione predefinita, git stash pop e git stash apply ripristinano le modifiche ma non preservano ciò che era in stage.

Mettiamo che tu abbia tre file modificati e ne abbia messi in stage due prima dello stash. Quando fai pop di quello stash, tutti e tre i file tornano come modifiche non in stage. Git perde traccia di quali file volevi committare.

La soluzione è usare il flag --index per ripristinare esattamente lo stato dello staging:

git stash pop --indexOfferto da

Questo ricrea esattamente working tree e index di prima dello stash. I file che erano in stage restano in stage. Quelli non in stage restano tali. Tutto torna esattamente com'era.

Ti servirà questo flag quando:

1. Sei nel mezzo di un commit preparato con cura e non puoi permetterti di perdere le informazioni di staging

2. Lavori con scenari di staging complessi, ad esempio quando hai usato git add -p per mettere in stage solo specifiche hunk

3. Vuoi che la working directory torni esattamente com'era prima dello stash, senza eccezioni

Nella maggior parte dei casi, non avrai bisogno di questo flag. Farai pop dello stash, vedrai cosa è tornato e metterai in stage ciò che serve.

Recuperare da errori con gli stash

Capiterà di eliminare uno stash che ti serviva o svuotare tutto lo stack per errore.

Se succede, il reflog di git potrebbe salvarti la giornata.

Il reflog traccia ogni cambiamento di riferimento nel repository, inclusi gli stash. Quando crei o elimini uno stash, Git lo registra nel reflog. Anche dopo aver eliminato uno stash, i commit esistono ancora per un po' come oggetti irraggiungibili.

Puoi trovare lo stash perduto cercando i commit irraggiungibili:

git fsck --unreachable | grep commitOfferto da

Ora puoi controllare ogni commit per trovare il tuo stash:

git show 066ded985342e585bc8e75c074add99ec1950f50Offerto da

Guarda il diff e il messaggio di commit per identificare quale sia il tuo stash perduto. Una volta trovato il commit giusto, recuperalo:

git stash apply 066ded985342e585bc8e75c074add99ec1950f50Offerto da

Questo applica lo stash perduto alla tua working directory come se non fosse mai stato eliminato.

Ancora meglio, previeni gli errori in partenza seguendo queste buone pratiche:

1. Scrivi messaggi di stash descrittivi così sai esattamente cosa stai eliminando. "Fix bug login" è meglio di "WIP" quando guardi una lista di cinque stash.

2. Usa git stash show -p prima di eliminare per confermare che sia lo stash giusto. Meglio spendere cinque secondi per verificare che cinque minuti per recuperare.

3. Pulisci regolarmente lo stack degli stash così non diventa disordinato. Uno stack con tre stash rilevanti è più facile da gestire di uno con 15 voci vecchie.

4. Usa apply invece di pop quando non sei al 100% sicuro di voler eliminare lo stash. Puoi sempre eliminarlo dopo aver verificato che tutto funzioni.

Il recupero via reflog funziona, ma è tedioso. Basta guardare l'immagine sopra per vedere quanti commit dovrei controllare manualmente — e questo è un progetto piccolo creato solo per questo articolo.

Best practice e linee guida di workflow

Usare bene gli stash significa seguire schemi che prevengono errori e mantengono il workflow pulito. Ti mostro il mio approccio preferito.

Pattern di workflow consigliati

Il workflow più sicuro segue uno schema semplice: stash con messaggio, cambio contesto, poi pop quando sei pronto a continuare.

# Lavora su feature-branch
git stash push -m "Feature work in progress"

git checkout main
# Lavoro urgente su main

# Torna indietro
git checkout feature-branch
git stash popOfferto da

Funziona nella maggior parte delle situazioni. Conservi il lavoro, gestisci l'interruzione e ripristini tutto in modo pulito.

Un altro pattern comune è il workflow "ispeziona prima del pop". Elenchi gli stash, esamini cosa c'è dentro e poi fai pop di quello giusto.

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

Questo passaggio extra di verifica ti evita di fare pop dello stash sbagliato o applicare lavoro obsoleto.

Alcuni sviluppatori preferiscono l'alternativa del "commit riluttante" allo stash. Invece di mettere nello stash, fanno un commit temporaneo con un messaggio tipo "WIP - not ready" e poi lo modificano o resettano in seguito. Funziona se non ti senti a tuo agio con gli stash o se vuoi che il lavoro sia tracciato nella cronologia del branch. Lo svantaggio è che finisci con log di commit disordinati se ti dimentichi di pulirli.

Integrazione con gli strumenti di sviluppo

La maggior parte delle GUI Git mostra visivamente gli stash e ti permette di fare pop o apply con un click.

Strumenti come GitKraken, Sourcetree e GitHub Desktop elencano gli stash in una sidebar. Puoi vedere il messaggio, ispezionare il diff e applicare o eliminare gli stash senza digitare comandi. È utile quando hai più stash e vuoi confrontarli affiancati.

L'estensione Git di VS Code mostra gli stash nel pannello di controllo del codice sorgente. Puoi cliccare col tasto destro per fare pop, apply o drop senza lasciare l'editor.

Le alias di shell rendono più veloce lo stash se preferisci la riga di comando. Aggiungi queste al tuo .bashrc o .zshrc:

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

Ora gst mette in stash il tuo lavoro, gstp lo fa pop, gstl elenca gli stash e gsts mostra il diff. Risparmi qualche tasto ogni volta.

Igiene dello stash e considerazioni di team

Gli stash sono locali alla tua macchina: non vengono mai pushati sui repository remoti.

Questo significa che i tuoi colleghi non possono vedere i tuoi stash e tu non puoi accedervi da un altro computer. Se devi condividere lavoro in corso, non metterlo in stash. Usa patch o branch temporanei.

Per condividere il lavoro via patch, esegui:

git stash show -p > my-work.patch
# Invia il file patch al tuo collega
# Lo applica con: git apply my-work.patchOfferto da

Ora invia il file patch al tuo collega e lo applicherà eseguendo git apply my-work.patch.

Per condividere il lavoro via branch temporanei, esegui:

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - authentication feature"
git push origin temp/work-in-progressOfferto da

Il tuo collega può fare pull del branch, rivedere il lavoro e continuare da lì.

Qualunque approccio tu scelga, mantieni sempre una buona igiene dello stash. Eviterai confusione e terrai gestibile lo stack locale. Ecco alcune buone pratiche da seguire:

1. Usa nomi descrittivi per ogni stash. "Aggiungi logica auth utente" ti dice cosa contiene. "WIP on feature-branch" non ti dice nulla.

2. Pulisci gli stash ogni settimana. Esegui git stash list ed elimina tutto ciò che è più vecchio di una settimana. Se non ti è servito in sette giorni, probabilmente non ti servirà affatto.

3. Non lasciare che il conteggio degli stash superi cinque. Più di cinque stash significa che li stai usando come archivio a lungo termine invece che come deposito temporaneo. O fai pop, o fai commit del lavoro, o eliminali.

4. Se lavori in team e qualcuno chiede: "Dov'è quel codice su cui stavi lavorando?", non rispondere mai: "È nel mio stash". Gli stash sono privati e temporanei: non servono per condividere o archiviare lavoro importante.

Conclusione

Ora sai come funziona git stash pop e quando usarlo.

Alla base, lo stash è semplice: salva il lavoro non committato, cambia contesto e ripristinalo più tardi. Ma i dettagli contano. Sapere quando usare pop rispetto a apply, come gestire i conflitti e quando creare branch dagli stash ti farà risparmiare ore di frustrazione.

La cosa più importante da ricordare è che gli stash sono archivi temporanei, non backup permanenti. Usa messaggi descrittivi, pulisci regolarmente e non lasciare che lo stack superi cinque voci. Se devi condividere il lavoro o conservarlo a lungo, fai commit su un branch.

Se ti è piaciuto questo articolo e vuoi migliorare con Git, le prossime tappe migliori sono i nostri corsi Intermediate Git e Intermediate GitHub Concepts.