Git stash pop: behoud werk bij het wisselen van branches

Heb je half-af werk dat nog niet klaar is om te committen, maar moet je nú van context wisselen? Maak dan geen "WIP"-commit. En kopieer-plak je wijzigingen ook niet in een tekstbestand alsof het 2005 is. git stash is alles wat je nodig hebt.

Dit commando is dé manier om niet-gecommitte werk te bewaren terwijl je van context wisselt. Het laat je wijzigingen tijdelijk opslaan, urgente taken op andere branches afhandelen en alles precies herstellen waar je was gebleven.

In dit artikel laat ik je zien hoe git stash pop werkt, wanneer je het gebruikt in plaats van git stash apply, en hoe je herstelt wanneer er onvermijdelijk conflicten opduiken.

Als je nieuw bent met Git en het concept stashing verwarrend vindt, zorg dan eerst dat je de basis beheerst. Onze cursussen Introduction to Git en Introduction to GitHub helpen je razendsnel op weg.

Git stash begrijpen

Git stash is je tijdelijke opslag voor niet-gecommitte wijzigingen.

Zie het als een klembord voor je werk. Je hebt wijzigingen in je working directory die nog niet klaar zijn om te committen, maar je moet van branch wisselen of updates van remote binnenhalen. In plaats van je werk te verliezen of een WIP-commit te maken, stash je het.

Het commando slaat je aanpassingen op en zet je working directory terug zodat die overeenkomt met de HEAD-commit.

Het idee achter stashing in Git

Stashing lost een simpel probleem op: Git laat je niet van branch wisselen met niet-gecommitte wijzigingen.

Stel, je werkt aan een feature wanneer er een bugreport binnenkomt. Je moet meteen naar een andere branch, maar je hebt halfgeschreven code en aangepaste bestanden. Een commit is niet logisch omdat je werk onvolledig is. Een geforceerde checkout zou je wijzigingen verliezen.

Dán stash je.

Dit zijn de meest voorkomende scenario’s waarin stashing helpt:

1. Van branch wisselen voor urgent werk: Je zit midden in een feature wanneer je een productiebug moet fixen.
2. Remote wijzigingen pullen: Je teamgenoot heeft updates gepusht en jij moet pullen, maar je hebt lokale aanpassingen.
3. Rommige commits vermijden: Je bent nog niet klaar om te committen, maar je wilt een schone working directory voor rebasen of mergen.
4. Experimentele code bewaren: Je wilt een andere aanpak proberen zonder je huidige werk te verliezen

Stashing is snel en omkeerbaar — je hoeft niet na te denken over commitberichten of branchnamen.

De stash-stackarchitectuur

Git beheert stashes in een last-in, first-out (LIFO)-stack.

Elke keer dat je stasht, maakt Git een nieuw item bovenaan de stack. De meest recente stash wordt stash@{0}, en oudere stashes schuiven naar beneden: stash@{1}, stash@{2}, enzovoort.

Onder de motorkap is elke stash eigenlijk een commit — of preciezer, een set commits. Git creëert een commitstructuur met meerdere parents die het volgende opslaat:

1. Je wijzigingen in de working directory
2. Je gestagede wijzigingen (de index)
3. Ongetrackte bestanden (als je de u-vlag gebruikte)

Door deze structuur zijn stashes niet zomaar snapshots. Het zijn volwaardige commits die Git later terug kan mergen in je working directory.

Je kunt stashes op twee manieren refereren — op index met stash@{0}-syntaxis, of via git stash list om het bericht te vinden dat je gaf en die specifieke stash te refereren. De index is sneller voor recente stashes, maar berichten zijn handiger wanneer je meerdere stashes hebt opgeslagen.

Zo ziet een typische stash-stack eruit:

Het voorvoegsel WIP on betekent dat je git stash zonder bericht hebt gebruikt. Het voorvoegsel On betekent dat je een aangepast bericht hebt meegegeven met git stash push -m.

Stashes leven alleen in je lokale repository — ze worden niet naar remote gepusht. Zo blijft je tijdelijke werk precies waar het hoort: op jouw machine, klaar om te herstellen wanneer je het nodig hebt.

Stashes maken, beheren en bekijken

Het basiscommando git stash is genoeg om te beginnen, maar het is gemakzuchtig. Je eindigt met een stapel "WIP on branch-name"-items die je niets vertellen over de inhoud. Over zes weken weet je niet meer welke stash de bugfix bevatte en welke je halfafgemaakte refactor.

Ik laat je nu zien hoe je het vanaf het begin goed aanpakt.

Stashes maken met passende metadata

De eenvoudigste manier om te stashen is gewoon git stash typen:

git stashMogelijk gemaakt door

Dit slaat je wijzigingen op, maar het bericht "WIP on main" is niet erg informatief. Je ziet niet wat erin zit zonder het te inspecteren.

Draai in plaats daarvan git stash push -m met een beschrijvend bericht:

git stash push -m "Updated file.txt"Mogelijk gemaakt door

Nu is je stash-lijst wél informatief:

Het verschil is duidelijk. De ene entry vertelt je precies wat je deed, terwijl de andere je laat gissen.

Schrijf berichten alsof je notities achterlaat voor je toekomstige zelf. "Auth-logica toevoegen", "Navbar-bug fixen" of "Experimenteren met nieuw API-ontwerp" wint het altijd van generieke WIP-berichten.

Ongetrackte of genegeerde bestanden meenemen

Standaard slaat git stash alleen getrackte bestanden op — bestanden die Git al kent.

Ongetrackte bestanden blijven in je working directory. Dat verrast mensen vaak wanneer ze stashen, van branch wisselen en hun nieuwe bestanden daar nog zien staan.

Dit is wat er gebeurt:

echo "new_feature.py" > new_feature.py
git stashMogelijk gemaakt door

Het bestand is niet gestasht omdat Git het nog niet trackt:

Gebruik hiervoor de vlag -u om ongetrackte bestanden te stashen:

git stash push -u -m "Added a Python file for a new cool feature"Mogelijk gemaakt door

Dit stasht zowel getrackte als ongetrackte bestanden. Je working directory is volledig schoon.

Tip: Je kunt de vlag -a toevoegen om ook genegeerde bestanden mee te nemen. Het stasht getrackte bestanden, ongetrackte bestanden en bestanden in je .gitignore. Je hebt dit zelden nodig, tenzij je buildproblemen debugt of een volledig schone snapshot van alles wilt bewaren.

Hier is een spiekbriefje zodat je weet wanneer je welke vlag gebruikt:

1. Geen vlag: Je hebt alleen bestaande bestanden aangepast

2. u-vlag: Je hebt nieuwe bestanden toegevoegd die nog niet getrackt worden

3. a-vlag: Je wilt alles opslaan, inclusief buildoutputs of tijdelijke bestanden

Meestal gebruik je -u. Dat is de veiligste keuze wanneer je nieuwe bestanden hebt aangemaakt tijdens de ontwikkeling.

Gedeeltelijk of selectief stashen

Je hoeft niet alles in je working directory te stashen.

Stel dat je twee bugs hebt gefixt, maar je wilt er maar één stashen. Of je hebt wijzigingen in vijf bestanden, maar alleen drie horen bij de feature die je wilt bewaren.

Je kunt specifieke bestanden stashen met pathspec:

git stash push -m "New files" new_file.txt new_file_2.txtMogelijk gemaakt door

Dit stasht alleen new_file.txt en new_file_2.txt. De rest blijft in je working directory.

Je kunt ook wildcards gebruiken:

git stash push -m "Stash all txt files" *.txtMogelijk gemaakt door

Of je kunt --patch gebruiken voor interactief stashen:

git stash push --patchMogelijk gemaakt door

Git loopt elke wijziging langs en vraagt of je die wilt stashen. Je antwoordt y (ja), n (nee), of s (split deze hunk in kleinere stukken).

Dit is handig wanneer je gerelateerde en ongerelateerde wijzigingen in hetzelfde bestand hebt gemixt. Je stasht het featurewerk en laat de debugcode achter.

Zo ziet de interactieve prompt eruit:

Stashes op lijsten zetten en bekijken

Zoals je al hebt gezien, kun je git stash list draaien om alles te zien wat je hebt gestasht:

De meest recente stash is altijd stash@{0}. Oudere stashes schuiven in de index naar beneden.

Als je goede berichten hebt geschreven, kun je deze lijst scannen en precies weten wat er in elke stash zit. Zo niet, dan moet je ze één voor één inspecteren.

Gebruik git stash show voor een samenvatting:

Dit toont welke bestanden zijn gewijzigd en hoeveel regels zijn toegevoegd of verwijderd.

Gebruik eventueel git stash show -p om het volledige verschil te zien:

De -p-vlag toont de daadwerkelijke codewijzigingen, net als git diff. Zo bevestig je dat je de juiste stash popt voordat je git stash pop draait.

Wat Git stash pop precies doet

Laten we nu bespreken wat git stash pop precies doet en waarom je het zou gebruiken.

Fundamenteel gedrag en syntaxis

Het commando git stash pop doet twee dingen: het past je gestashte wijzigingen toe en verwijdert die stash daarna uit de stack.

De basis-syntaxis is:

git stash popMogelijk gemaakt door

Dit popt de meest recente stash (stash@{0}) en verwijdert die uit je stash-lijst.

Je kunt ook een specifieke stash poppen door de index te refereren:

git stash pop stash@{1}Mogelijk gemaakt door

Dit past stash@{1} toe en verwijdert hem, maar er is een addertje — de overige stashes schuiven omhoog. Wat stash@{2} was, wordt stash@{1}, enzovoort.

Hoe Git een stash pop verwerkt

Wanneer je git stash pop draait, voert Git achter de schermen een three-way merge uit.

Het vergelijkt drie toestanden:

1. De basiscommit (waar je de stash maakte)
2. Je huidige HEAD-commit
3. De gestashte wijzigingen

Als de merge zonder conflicten slaagt, past Git je wijzigingen toe en verwijdert de stash. Je working directory ziet er precies zo uit als vóór het stashen.

Hier is een eenvoudig workflowvoorbeeld:

# Je werkt aan een feature
echo "new feature code" >> feature.py
git stash push -m "Half-finished feature work"

# Wissel naar nieuwe branch en maak ongerelateerde wijzigingen
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Fix critical bug"

# Ga terug naar je andere branch
git checkout main

# Pop je gestashte werk
git stash popMogelijk gemaakt door

Als Git niet schoon kan mergen, krijg je een conflict. De stash blijft in je stack omdat de pop niet succesvol is afgerond. Je ziet conflictmarkers in je bestanden, net als bij een gewone mergeconflict.

Wanneer er conflicten ontstaan, moet je die handmatig oplossen, de gefixte bestanden stagen en committen. De stash verdwijnt niet automatisch, dus je moet git stash drop draaien nadat je alles hebt opgelost.

Stashes toepassen over branches heen

Stashes zijn niet aan een specifieke branch gekoppeld.

Je kunt een stash maken op bugfix, naar main switchen en die stash daar poppen. Het kan Git niet schelen waar de stash vandaan komt — het probeert de wijzigingen toe te passen op de branch waar je nu op staat.

Dit opent handige workflows:

1. Werk verplaatsen tussen branches: Je begon op de verkeerde branch te coderen. In plaats van te resetten en werk te verliezen, stash je het, switch je naar de juiste branch en pop je het daar.

2. Taken herorganiseren: Je hebt een week geleden experimentele code gestasht. Nu wil je het op een andere branch proberen om te zien of het daar beter werkt.

3. Wijzigingen testen in verschillende contexten: Je hebt een bugfix gestasht en wilt die op meerdere branches testen vóór je commit. Gebruik git stash apply in plaats van pop om de stash te behouden, test op verschillende branches en pop hem op de branch waar je wilt committen. Straks meer over apply.

Zolang de wijzigingen niet conflicteren met je huidige branch, wordt de stash netjes toegepast — dat is de hoofdgedachte om te onthouden.

Git stash pop vs git stash apply

Ontwikkelaars vragen zich vaak af of ze git stash pop of git stash apply moeten gebruiken.

Het belangrijkste verschil: stash-persistentie

Het hoofdzakelijke verschil is simpel: pop verwijdert de stash na het toepassen, terwijl apply hem in je stack laat staan.

Met pop zeg je: "Ik ben klaar met deze stash — pas hem toe en gooi hem weg." Met apply zeg je: "Ik heb dit misschien later nog nodig."

Dit beïnvloedt je workflow op twee manieren:

1. Veiligheid: Als er iets misgaat tijdens een pop en je moet herstellen, is de stash weg. Met apply blijft de stash als back-up in je stack.

2. Opschonen: Gebruik van pop houdt je stash-lijst automatisch schoon. Bij apply moet je later handmatig git stash drop draaien om stashes waar je klaar mee bent te verwijderen.

De meeste ontwikkelaars gebruiken standaard pop omdat dat opschoner is. Maar apply is beter wanneer je niet zeker weet of de stash op je huidige branch werkt, of wanneer je dezelfde wijzigingen op meerdere branches wilt testen.

Voorspelbaarheid, risico en verschuivende index

Hier wordt pop lastig — stash-indices verschuiven wanneer je uit het midden van je stack popt.

Stel, je hebt drie stashes:

stash@{0}: Feature work
stash@{1}: Bug fix
stash@{2}: Experimental codeMogelijk gemaakt door

Als je stash@{1} popt, schuiven de overgebleven stashes omhoog:

stash@{0}: Feature work
stash@{1}: Experimental codeMogelijk gemaakt door

Dat kan problemen geven als je Git-operaties scriptt of meerdere pop-commando’s na elkaar draait. Je popt stash@{1} en probeert dan stash@{2} te poppen, maar die index bestaat niet meer.

Het commando apply heeft dit probleem niet. Indices verschuiven alleen wanneer je expliciet git stash drop draait. Je kunt stashes in elke volgorde toepassen zonder dat de stack onder je verandert.

Identieke conflictafhandeling

Beide commando’s behandelen conflicten precies hetzelfde.

Als Git je gestashte wijzigingen niet schoon kan mergen, krijg je conflictmarkers in je bestanden. Het verschil zit in wat er met de stash gebeurt:

1. Met pop: De stash blijft in je stack omdat de pop niet succesvol is afgerond

2. Met apply: De stash blijft in je stack (wat toch al zo is)

In beide gevallen moet je de conflicten handmatig oplossen, de opgeloste bestanden stagen met git add en de stash verwijderen met git stash drop (als je apply gebruikte).

De workflow voor conflictoplossing is identiek — het enige verschil is of de stash bij succes automatisch was verwijderd.

Wanneer kies je welke

Gebruik git stash pop wanneer:

1. Je een stash één keer toepast en er daarna klaar mee bent
2. Je je stash-lijst automatisch schoon wilt houden
3. Je aan één branch werkt en de stash elders niet nodig hebt

Gebruik git stash apply wanneer:

1. Je dezelfde wijzigingen op meerdere branches wilt testen
2. Je niet zeker weet of de stash schoon zal toepassen
3. Je Git-operaties scriptt en voorspelbare indices nodig hebt
4. Je een vangnet wilt als er iets misgaat

Conflicten afhandelen bij stash pops

Conflicten ontstaan wanneer Git je gestashte wijzigingen niet schoon kan mergen. In deze sectie laat ik je zien hoe je ermee omgaat.

Wanneer conflicten ontstaan en waarom

Een conflict ontstaat tijdens de three-way merge die Git uitvoert wanneer je een stash popt.

Git vergelijkt drie versies van je code:

1. De basiscommit waar je de stash maakte
2. Je huidige HEAD-commit
3. De gestashte wijzigingen

Als dezelfde regels in zowel je huidige branch als in de stash zijn gewijzigd, weet Git niet welke versie hij moet houden. Dat is een conflict.

Veelvoorkomende oorzaken van stash-popconflicten:

1. Je hebt hetzelfde bestand op beide branches aangepast: Je stasht wijzigingen in een bestand, wisselt van branch en bewerkt hetzelfde bestand opnieuw vóór het poppen
2. Iemand anders heeft wijzigingen gepusht: Je stasht werk, pullt updates van remote, en die updates raken dezelfde code
3. Je hebt gerebased of commits gecherry-picked: De basiscommit die Git verwacht bestaat niet meer, wat tot mergemismatches leidt

Kort gezegd: hoe langer een stash blijft liggen, hoe groter de kans op conflicten wanneer je hem uiteindelijk popt.

Workflow voor conflictoplossing

Wanneer er een conflict optreedt, pauzeert Git de pop en markeert de conflicten in je bestanden:

Je bestand bevat nu conflictmarkers:

Alles tussen <<<<<<< Updated upstream en ======= is je huidige code. Alles tussen ======= en >>>>>>> Stashed changes komt uit de stash.

Zo los je het op:

1. Open het conflicterende bestand en beslis welke versie je behoudt (of combineer beide)

2. Verwijder de conflictmarkers (<<<<<<<, =======, >>>>>>>)

3. Stage het opgeloste bestand met git add

4. Drop de stash handmatig met git stash drop — onthoud dat hij niet automatisch verdwijnt.

Alternatieve strategieën

Als je geen zin hebt om conflicten in je huidige branch op te lossen, gebruik dan git stash branch.

Dit commando maakt een nieuwe branch aan vanaf de commit waar je de stash maakte en past de stash daar toe:

git stash branch temp-featureMogelijk gemaakt door

Git maakt een branch genaamd temp-feature, checkt die uit en popt je stash erop. Omdat de branch begint vanaf de exacte commit waar je stasht, zijn er geen conflicten. Ik bespreek dit verderop uitgebreider.

Je kunt ook een mislukte pop afbreken met git reset --merge:

git stash pop

# Conflicten verschijnen

git reset --mergeMogelijk gemaakt door

Dit maakt de pop-poging ongedaan en zet je working directory terug naar de staat van vóór de pop. De stash blijft in je stack.

Lopende stash-operaties afbreken

Als je een pop of apply bent gestart en volledig wilt terugkrabbelen, heb je opties.

Voor conflicten die je nog niet bent gaan oplossen, draai je het volgende:

git reset --mergeMogelijk gemaakt door

Dit annuleert de merge en ruimt je working directory op. Alles gaat terug naar hoe het was vóór je het stash-commando draaide.

Voor conflicten die je deels hebt opgelost, draai dit commando:

git reset --hard HEADMogelijk gemaakt door

Dit gooit alle wijzigingen in je working directory weg, inclusief eventuele fixes die je hebt gemaakt. Gebruik dit wanneer je er een rommeltje van hebt gemaakt en gewoon opnieuw wilt beginnen.

Onthoud dat dit commando niet-gecommitte werk vernietigt. Zorg dat je écht alles wilt weggooien voordat je het draait.

Na het afbreken staat je stash nog in de stack (tenzij je pop gebruikte en die slaagde vóórdat er conflicten optraden). Je kunt het later opnieuw proberen, of git stash branch gebruiken voor een schonere aanpak.

Stashes opruimen

Stashes stapelen zich snel op in langlopende projecten. Je stasht werk om een bug te fixen en vergeet het. Je maakt experimentele stashes die je nooit popt. Zes maanden later heb je 20 stashes en geen idee wat de helft bevat.

Daardoor wordt het lastiger om de stash te vinden die je nodig hebt. Je eindigt met git stash show -p op elk item te draaien om erachter te komen wat erin zit.

Het is enorme tijdverspilling, dus ruim je stashes regelmatig op.

Individuele stashes droppen

Gebruik git stash drop om een specifieke stash te verwijderen:

git stash drop stash@{2}Mogelijk gemaakt door

Dit verwijdert stash@{2} uit je stack. De overgebleven stashes schuiven omhoog — wat stash@{3} was, wordt stash@{2}.

Je kunt ook de meest recente stash droppen zonder een index te specificeren:

git stash dropMogelijk gemaakt door

Dit verwijdert standaard stash@{0}.

Uit jaren werken met Git zijn dit mijn topredenen om stashes te droppen:

1. Je realiseert je dat je de wijzigingen niet meer nodig hebt
2. Je hebt dubbele stashes (gebeurt vaker dan je denkt)
3. Een stash is zo oud dat je niet meer weet waar die voor was

Als je niet zeker weet of je een stash moet droppen, gebruik dan eerst git stash show -p om hem te inspecteren. Better safe than sorry.

De hele stash-stack leegmaken

Je kunt git stash clear gebruiken om alle stashes in één keer te verwijderen:

git stash clearMogelijk gemaakt door

Onthoud dat dit permanent is. Je kunt het niet ongedaan maken of de stashes achteraf herstellen.

Gebruik git stash clear alleen wanneer je absoluut zeker weet dat je geen van je gestashte werk nodig hebt.

Meestal kun je beter stashes individueel droppen zodat je niet per ongeluk iets verwijdert dat je nog nodig hebt.

Branches maken vanuit stashes

Soms is de schoonste oplossing om van een stash een eigen branch te maken. Dat voorkomt mergeconflicten en geeft je gestashte werk een degelijk thuis.

git stash branch gebruiken

Het commando git stash branch maakt een nieuwe branch en past je stash daarop toe:

Dit gebeurt er:

1. Git maakt een nieuwe branch feature-experiment vanaf de commit waar je de stash maakte

2. Git checkt die nieuwe branch uit

3. Git popt de stash op de branch

4. Git verwijdert de stash uit je stack (net als bij pop)

Omdat de branch begint op exact dezelfde commit als de stash, zijn er geen conflicten. De wijzigingen worden elke keer netjes toegepast.

Je kunt ook een specifieke stash gebruiken in plaats van de meest recente:

git stash branch new-feature stash@{2}Mogelijk gemaakt door

Veelvoorkomende use-cases

Een branch maken vanuit een stash is perfect voor experimentele features. Stel, je hebt een week geleden experimentele code gestasht en je wilt die nu netjes verder ontwikkelen zonder je huidige werk te verstoren.

Je krijgt een schone branch om aan het experiment te werken. Werkt het uit, dan merge je het terug. Werkt het niet, dan verwijder je de branch en ga je verder.

Het is ook geweldig voor lange rebasetrajecten. In plaats van potentiële conflicten tijdens de rebase, kun je alles stashen en er een branch van maken.

git stash push -m "WIP before rebase"
git rebase main
git stash branch temp-workMogelijk gemaakt door

Nu kun je de gestashte wijzigingen apart reviewen en beslissen hoe je ze na de rebase integreert.

Een branch maken is ook handig om grote of rommelige wijzigingen te isoleren. Stel dat je een enorme stash hebt met wijzigingen in 15 bestanden, waarvan de helft conflicteert met je huidige branch. Maak gewoon een nieuwe branch — geen gevecht nodig.

Je krijgt een dedicated branch waar je alles rustig kunt reviewen, netjes kunt committen en het daarna met een heldere geschiedenis terug kunt mergen.

Geavanceerde technieken en herstelopties

Tegenwoordig ben je vertrouwd met de basis van git stash, dus laat ik je wat geavanceerdere concepten zien.

Werken met specifieke stash-items

Je kunt elke stash in je stack poppen of applyen, niet alleen de meest recente.

Refereer gewoon op index om precies te pakken wat je nodig hebt:

git stash pop stash@{3}
git stash apply stash@{1}Mogelijk gemaakt door

Zo haal je oudere stashes op zonder de nieuwere aan te raken. Wanneer je een tussenliggende stash popt, schuiven alle indices eronder omhoog. Wat stash@{4} was, wordt stash@{3}, enzovoort. Als je Git scriptt of meerdere stashes na elkaar popt, breekt dit verschuiven je commando’s.

De oplossing is apply gebruiken in plaats van pop wanneer je voorspelbare indices nodig hebt:

git stash apply stash@{2}

# Drop hem handmatig wanneer je klaar bent
git stash drop stash@{2}Mogelijk gemaakt door

Zo houd je volledige controle over wanneer de stack verandert. Je past de stash toe, verifieert dat het goed werkte en dropt hem zelf. De indices verschuiven alleen wanneer jij dat expliciet aangeeft.

Gestagede staat herstellen

Standaard herstellen git stash pop en git stash apply je wijzigingen maar behouden ze niet wat er gestaged was.

Stel dat je drie bestanden had gewijzigd en er twee had gestaged voor commit voordat je stashte. Wanneer je die stash popt, komen alle drie de bestanden terug als ongestagede wijzigingen. Git raakt kwijt welke bestanden je wilde committen.

De oplossing is de vlag --index gebruiken om de stagingstaat precies te herstellen zoals die was:

git stash pop --indexMogelijk gemaakt door

Dit reconstrueert je exacte working tree en index van vóór de stash. Bestanden die gestaged waren, blijven gestaged. Bestanden die ongestaged waren, blijven ongestaged. Alles keert exact terug naar hoe het was.

Je hebt deze vlag nodig wanneer:

1. Je midden in het voorbereiden van een zorgvuldig gestagede commit zit en die staginginformatie niet kwijt kunt

2. Je met complexe staging-scenario’s werkt, zoals wanneer je met git add -p alleen specifieke hunks hebt gestaged

3. Je je working directory precies wilt hebben zoals vóór het stashen, zonder uitzonderingen

Meestal heb je deze vlag niet nodig. Je popt je stash, bekijkt wat er terugkwam en staged wat je nodig hebt.

Herstellen van stash-fouten

Vroeg of laat drop je een stash die je nodig had of maak je per ongeluk je hele stack leeg.

Als dat gebeurt, kan de reflog van Git je dag redden.

De reflog volgt elke referentiewijziging in je repository, inclusief stashes. Wanneer je een stash maakt of dropt, registreert Git dat in de reflog. Zelfs na het droppen bestaan de commits nog een tijdje als onbereikbare objecten.

Je kunt je verloren stash vinden door naar onbereikbare commits te zoeken:

git fsck --unreachable | grep commitMogelijk gemaakt door

Je kunt nu elke commit bekijken om je stash te vinden:

git show 066ded985342e585bc8e75c074add99ec1950f50Mogelijk gemaakt door

Kijk naar de diff en het commitbericht om te bepalen welke jouw verloren stash is. Zodra je de juiste commit hebt gevonden, herstel je hem:

git stash apply 066ded985342e585bc8e75c074add99ec1950f50Mogelijk gemaakt door

Dit past de verloren stash toe op je working directory alsof hij nooit gedropt was.

Nog beter: voorkom fouten door deze best practices te volgen:

1. Schrijf beschrijvende stash-berichten zodat je precies weet wat je dropt. "Fix login-bug" is beter dan "WIP" als je naar een lijst met vijf stashes kijkt.

2. Gebruik git stash show -p vóór het droppen om te bevestigen dat het de juiste stash is. Neem vijf seconden om te verifiëren in plaats van vijf minuten om te herstellen.

3. Ruim je stash-stack regelmatig op zodat die niet rommelig wordt. Een stack met drie relevante stashes navigeert makkelijker dan eentje met 15 oude items.

4. Gebruik apply in plaats van pop wanneer je niet 100% zeker weet dat je de stash wilt verwijderen. Je kunt hem altijd later droppen nadat je hebt geverifieerd dat alles werkt.

Herstellen via reflog werkt, maar het is omslachtig. Kijk maar naar de bovenstaande afbeelding om te zien hoeveel commits ik handmatig zou moeten checken — en dit is een klein project, alleen voor dit artikel gemaakt.

Best practices en workflowrichtlijnen

Stashes goed gebruiken betekent patronen volgen die fouten voorkomen en je workflow schoon houden. Ik laat je mijn vaste aanpak zien.

Aanbevolen workflowpatronen

De veiligste stash-workflow volgt een simpel patroon: stash met een bericht, wissel van context en pop wanneer je klaar bent om verder te gaan.

# Werk op feature-branch
git stash push -m "Feature work in progress"

git checkout main
# Doe urgent werk op main

# Ga terug
git checkout feature-branch
git stash popMogelijk gemaakt door

Dit werkt in de meeste situaties. Je bewaart je werk, handelt de onderbreking af en herstelt alles netjes.

Een ander veelgebruikt patroon is de "inspecteren vóór pop"-workflow. Je toont je stashes, bekijkt wat erin zit en popt dan de juiste.

git stash list
git stash show -p stash@{1}
git stash pop stash@{1}Mogelijk gemaakt door

Deze extra controle voorkomt dat je de verkeerde stash popt of verouderd werk toepast.

Sommige ontwikkelaars kiezen het alternatief van de "terughoudende commit" in plaats van stashen. In plaats van te stashen maken ze een tijdelijke commit met een bericht als "WIP - not ready" en amenden of resetten die later. Dit werkt als je je niet comfortabel voelt met stashes of als je het werk in je branchgeschiedenis wilt vastleggen. Nadeel: je eindigt met rommelige commitlogs als je vergeet op te ruimen.

Integratie met ontwikkeltools

De meeste Git-GUI’s tonen je stashes visueel en laten je met een klik poppen of applyen.

Tools zoals GitKraken, Sourcetree en GitHub Desktop tonen je stashes in een zijbalk. Je ziet het bericht, kunt de diff bekijken en stashes toepassen of droppen zonder commando’s te typen. Handig als je meerdere stashes hebt en die naast elkaar wilt vergelijken.

De Git-extensie van VS Code toont stashes in het source control-paneel. Met rechtsklik kun je poppen, applyen of droppen zonder je editor te verlaten.

Shell-aliases maken stashen sneller als je de commandoregel verkiest. Voeg deze toe aan je .bashrc of .zshrc:

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

Nu stash je werk met gst, gstp popt, gstl toont je stashes en gsts laat de diff zien. Je bespaart elke keer wat toetsaanslagen.

Stashhygiëne en teamoverwegingen

Stashes zijn lokaal op jouw machine — ze worden nooit naar remotes gepusht.

Dat betekent dat je teamgenoten je stashes niet zien en jij ze niet vanaf een andere computer kunt benaderen. Als je werk in uitvoering moet delen, stash het dan niet. Gebruik patches of tijdelijke branches.

Om werk via patches te delen, draai je het volgende:

git stash show -p > my-work.patch
# Stuur het patchbestand naar je teamgenoot
# Die past het toe met: git apply my-work.patchMogelijk gemaakt door

Stuur nu het patchbestand naar je teamgenoot, en die past het toe door git apply my-work.patch te draaien.

Om werk via tijdelijke branches te delen, draai je dit:

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - authentication feature"
git push origin temp/work-in-progressMogelijk gemaakt door

Je teamgenoot kan de branch pullen, het werk reviewen en vandaaruit doorgaan.

Wat je ook kiest als vaste aanpak, houd altijd een goede stashhygiëne aan. Dat voorkomt verwarring en houdt je lokale stack beheersbaar. Dit zijn goede gewoonten:

1. Gebruik beschrijvende namen voor elke stash. "Add user auth logic" vertelt wat erin zit. "WIP on feature-branch" vertelt niets.

2. Ruim je stashes wekelijks op. Draai git stash list en drop alles ouder dan een week. Als je het in zeven dagen niet nodig had, heb je het waarschijnlijk niet meer nodig.

3. Laat je stash-aantal niet boven de vijf komen. Meer dan vijf stashes betekent dat je ze als langdurige opslag gebruikt in plaats van als tijdelijke parkeerplek. Pop ze, commit het werk of drop ze.

4. Als je in een team werkt en iemand vraagt: "Waar is die code waar je aan werkte?", antwoord dan nooit: "In mijn stash." Stashes zijn privé en tijdelijk — niet om werk te delen of te archiveren dat ertoe doet.

Conclusie

Je weet nu hoe git stash pop werkt en wanneer je het gebruikt.

In de kern is stashen simpel: sla je niet-gecommitte werk op, wissel van context en herstel het later. Maar de details doen ertoe. Weten wanneer je pop tegenover apply gebruikt, hoe je conflicten afhandelt en wanneer je branches uit stashes maakt, bespaart je uren frustratie.

De belangrijkste les is dat stashes tijdelijke opslag zijn, geen permanente back-ups. Gebruik beschrijvende berichten, ruim regelmatig op en laat je stack niet groeien voorbij vijf items. Als je werk wilt delen of langdurig wilt bewaren, commit het dan op een branch.

Als dit artikel je beviel en je beter wilt worden in Git, zijn onze cursussen Intermediate Git en Intermediate GitHub Concepts je volgende beste halte.