aslain.dev
0%
01 Hizmetler 02 Hakkımda 03 Projeler 04 Stack 05 Blog 06 İletişim
← Tüm makaleler Tools & DevOps

git reset, revert en stash: wijzigingen correct ongedaan maken

Er is niet één manier om werk in Git ongedaan te maken, en git reset revert verwarren met git stash is een van de meest voorkomende bronnen van verwarring. Alle drie voelen als "ongedaan maken", maar ze doen heel verschillende dingen: de een parkeert wijzigingen voor later, de een spoelt de geschiedenis terug, en de een maakt een nieuwe commit die een wijziging terugdraait zonder het verleden aan te raken. Weten welke je moet kiezen, is het verschil tussen een avond werk kwijtraken en een schone geschiedenis behouden.

Drie commando's, drie verschillende doelen

Laten we eerst het mentale model scherp krijgen. Git heeft drie gebieden: de werkmap (working directory), de staging-area (index) en de commitgeschiedenis (HEAD). Wat deze commando's onderscheidt, is welk van die gebieden ze aanraken.

  • git stash — zet niet-gecommitte wijzigingen in je werkmap en index opzij en brengt de boom terug naar de laatste commit. Er wordt niets vernietigd; je kunt het later terughalen.
  • git reset — verplaatst HEAD (en optioneel de index en de werkmap) naar een andere commit. Het herschrijft de geschiedenis.
  • git revert — maakt een nieuwe commit die het effect van een eerdere commit terugdraait. De geschiedenis blijft intact, met een "ongedaan maken" erbovenop.

git stash: werk in uitvoering veilig parkeren

Je bent halverwege een feature wanneer je opeens van branch moet wisselen om een urgente fix te leveren, maar je huidige werk is nog niet klaar om te committen. Daar is git stash precies voor.

git stash push -m "half afgemaakt filterformulier"
# de boom is nu schoon, wissel van branch, doe de hotfix...
git stash list
git stash pop      # herstel de laatste stash en verwijder hem uit de lijst
git stash apply    # herstel maar houd hem in de lijst

Gebruik git stash -u om ook niet-getrackte bestanden mee te nemen. Met meerdere stashes kun je er een op index aanwijzen, bijvoorbeeld git stash pop stash@{1}. Een stash is als een tijdelijke zak: je zet werk opzij zonder te committen of de branch te vervuilen. Het is echter geen langetermijnopslag — in plaats van werk dagenlang in een stash te laten staan, is een WIP-commit veiliger.

git reset: HEAD terugspoelen

git reset is het krachtigste en meest verkeerd begrepen commando. De drie modi zijn drie niveaus van hardheid:

  • --soft — verplaatst alleen HEAD. Je wijzigingen blijven in de index staan, alsof je net git add had gedaan. Ideaal om de laatste paar commits tot één samen te voegen.
  • --mixed (de standaard) — verplaatst HEAD en reset de index. Wijzigingen blijven als "unstaged" in de werkmap staan.
  • --hard — reset HEAD, de index en de werkmap in één keer. Alles wat niet is gecommit, is weg.
# Voeg de laatste 3 commits samen tot één (zonder de wijzigingen te verliezen)
git reset --soft HEAD~3
git commit -m "filterfunctie"

# Maak het stagen van een per ongeluk toegevoegd bestand ongedaan (inhoud blijft)
git reset HEAD bestand.php

# LET OP: dwing de werkboom terug naar de laatste commit
git reset --hard HEAD

De gouden regel: gebruik git reset alleen op commits die je nog niet hebt gedeeld (gepusht). Als je commits met reset verwijdert op een gedeelde branch en met --force pusht, loopt ieders geschiedenis uiteen van de jouwe.

git revert: gedeelde geschiedenis veilig ongedaan maken

Als een foute commit al op main staat en anderen die hebben gepulld, kun je de geschiedenis niet wissen. git revert is hier het juiste gereedschap: het voegt een nieuwe commit toe die alles wat de foute commit deed terugdraait.

# Draai een specifieke commit terug
git revert a1b2c3d

# Draai een merge-commit terug — geef aan welke mainline je behoudt
git revert -m 1 <merge-sha>

# Pas de tegengestelde wijziging toe zonder een commit te maken
git revert --no-commit a1b2c3d

Revert breekt de geschiedenis niet, wat het de veiligste keuze maakt bij teamwork en op productiebranches. In plaats van de tijdlijn te herschrijven voor een fout die iedereen kan zien, laat je een eerlijke registratie achter die zegt: "ik heb deze commit teruggedraaid".

Welke, wanneer?

  • Half afgemaakt werk opzij zetten om van branch te wisselen → stash
  • Commits die je nog niet hebt gepusht samenvoegen of opschonen → reset --soft of git commit --amend
  • Een verkeerd gestaged bestand uit de index halen → reset (mixed)
  • Lokaal alles terugzetten naar de laatste commit → reset --hard (wees voorzichtig)
  • Een gedeelde/gepushte commit ongedaan maken → revert

Als je per ongeluk iets hebt verwijderd: de reflog redt je

Commits waarvan je denkt dat je ze met git reset --hard bent kwijtgeraakt, staan er meestal nog. Git registreert elke beweging van HEAD in de reflog:

git reflog
# zoek de sha van de doelcommit in de uitvoer, en dan:
git reset --hard a1b2c3d
# of haal de verloren commit in een nieuwe branch
git branch herstel a1b2c3d

Reflog-vermeldingen worden standaard 90 dagen bewaard, dus controleer voordat je in paniek raakt altijd eerst de reflog.

Veelgestelde vragen

Kan ik bestanden herstellen die ik met git reset --hard ben kwijtgeraakt?

Als de verloren wijziging eerder was gecommit, ja: vind de commit met git reflog en ga ernaartoe. Maar wijzigingen die nooit zijn gecommit en alleen in de werkmap stonden, worden door --hard permanent verwijderd; die kan de reflog niet herstellen.

Kan ik resetten na een push?

Technisch wel, met --force, maar doe het niet op gedeelde branches. Als anderen die commits hebben gepulld, splitst de geschiedenis. Gebruik in plaats daarvan git revert; dat geeft hetzelfde resultaat zonder risico.

Wat is het kernverschil tussen stash en reset?

Stash is om wijzigingen op te slaan en later terug te geven zonder de geschiedenis aan te raken. Reset verplaatst HEAD en de index daadwerkelijk. Parkeer je werk "om later verder te gaan", denk dan aan stash; bewerk je de geschiedenis, denk dan aan reset.

Laten we je ongedaan-maken-strategie helder krijgen. Wil je een solide opzet voor je Git-flow, je releasebeheer of je CI/CD-pijplijn? Neem contact op en we bouwen samen de veiligste workflow voor jouw project.

Bu kategorideki tüm yazılar →

Devamı için