# Näin kumoat Claude Coden muutokset: /rewind ja git > Palautustilat, tarkistuspisteiden rajoitukset, git checkout, stash, reflog ja suojaus tuhoavilta komennoilta. Viisi tapaa palauttaa tila. Source: https://ailoot.ai/blog/fi/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/fi/claude-code-undo-changes/ Language: fi Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-88e4b6c05311a431ff6a5e5293545d08869f999984184679f1bf9c222dbc8de8 [Käytännön tietoa Ailootin käytöstä on dokumentaatiossa](https://ailoot.ai/docs/). ## Mitä kumoaminen Claude Codessa tarkoittaa, ja miksi kolme tasoa ei riitä?
Tärkeimmät kohdat Claude Codessa kumoamiseen on kolme tasoa: sisäänrakennettu `/rewind`-komento (välitön palautus istunnon aikana), `git checkout` (palautus viimeisimpään commit-tilaan) ja `git reflog` (katastrofitilanteen turvaverkko, jos joku on suorittanut `git reset --hard` -komennon). Kukin taso kattaa oman virheluokkansa, ei mitään sen rajojen ulkopuolelta. Jos tunnet vain `/rewind`-komennon, olet ensimmäisen vakavan mokan kohdalla pahassa pulassa.
Otin `/rewind`-komennon käyttöön ensimmäisellä viikollani Claude Coden parissa, kun se rikkoi projektini todennuslogiikan kahdella promptilla. Kumoaminen toi helpotuksen, ja jatkoin työtä. Kuukautta myöhemmin tuli toinen tilanne: kirjoitin skeeman migraatiota, Claude auttoi, tein commitin ja vaihdoin haaraa – sitten tajusin unohtaneeni tarpeellisen vaiheen. `/rewind` ei auttanut, koska istunto oli jo vaihtunut. `git checkout` edelliseen commitiin auttoi. Kuukautta myöhemmin pyysin agenttia vahingossa ”palauttamaan kaiken viimeisimpään pushiin”, ja se suoritti `git reset --hard` -komennon, joka tuhosi kolmen tunnin työn. `git reflog` pelasti minut – tuhottujen commitien hashit olivat yhä tallella. Nämä kolme tarinaa kuvaavat kolmea eri tavoin toimivaa suojaustasoa, jotka auttavat eri virheisiin ja joita kaikkia tarvitaan. Tässä oppaassa käydään läpi jokainen taso komentoineen, rajoituksineen ja esimerkkeineen. Lisäksi näytetään, miten projekti kannattaa määrittää etukäteen, jotta Claude ei kaada sitä heti ensimmäisellä kerralla. **3 kumoamisen tasoa – mitä ja milloin:** | Taso | Komento | Kattaa | EI kata | |----|----|----|----| | 1\. Istunnon aikana | `/rewind` tai `Esc Esc` | Tiedostot, joita Claude on muuttanut omilla työkaluillaan; keskusteluhistoria | Bash-komennot, ulkoiset editorit, tietokantamigraatiot | | 2\. Ennen committia | `git checkout .` tai `git stash` | Kaikki tiedostojen committaamattomat muutokset | Commitoidut commitit | | 3\. Katastrofi | `git reflog` + `git reset --hard ` | `reset --hard`-komennolla tai force-pushilla tuhotut commitit | Tuhoavat bash-komennot (rm, tietokantamigraatiot) | Käymme seuraavaksi läpi jokaisen tason: mitä tarkalleen pitää tehdä, mitkä ovat sudenkuopat ja miten asiat määritetään niin, ettei mitään tarvitse kumota, koska mikään ei mennyt rikki. ## Miten /rewind avataan: komennolla vai painamalla Esc-Esc?
Tärkeimmät kohdat Claude Codessa Rewind-valikon voi avata kahdella tavalla. Ensimmäinen on kirjoittaa `/rewind` syötekenttään. Toinen on painaa `Esc` kahdesti, kun syötekenttä on tyhjä. Jos kentässä on tekstiä, kaksoispainallus ensin tyhjentää sen ja tallentaa syötehistoriaan; toinen kaksoispainallus avaa valikon. `/rewind`-komennon alias on `/checkpoint`.
Jokaisen vastauksen jälkeen Claude ottaa automaattisesti tilannekuvan kaikista tiedostoista, joita se muokkasi kyseisessä istunnossa. Tilannekuvat tallennetaan hakemistoon `~/.claude/file-history/{sessionId}/`, ja niitä säilytetään enintään 30 päivää. Tilannekuvat ovat inkrementaalisia: niihin tallennetaan vain tilojen väliset erot, ei koko tiedostoa. Oletusarvoisesti yhdessä istunnossa säilytetään enintään 100 tilannekuvaa. Tämä tarkoittaa, että useimmissa todellisissa projekteissa käytettävissäsi on milloin tahansa täydellinen historia kaikista Clauden työpäivän aikana tekemistä muutoksista. Avaa palautusvalikko painamalla `Esc` kahdesti, kun syötekenttä on tyhjä: ``` [user-input is empty] > _ [press Esc, Esc] Rewind to which message? 1. Create a migration for the User table (3 files changed) 2. Add the lastLoginAt field (1 file changed) 3. Rewrite the authorization logic (5 files changed) ... ``` Jos syötekentässä on tekstiä, ensimmäinen `Esc`-näppäimen kaksoispainallus tyhjentää tekstin ja tallentaa sen `Ylös`-näppäimellä selattavaan historiaan. Tämä on hyödyllistä, jos olet jo alkanut kirjoittaa ja huomaat tarvitsevasi palautusta. Lainaus Anthropicin virallisesta dokumentaatiosta:

Jos kehoterkentässä on tekstiä, Esc-näppäimen kaksoispainallus tyhjentää ensin tekstin valikon avaamisen sijaan. Tyhjennetty teksti tallennetaan syötehistoriaan, joten voit palauttaa sen ylänuolella palautusvalikon jälkeen.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
`/rewind` tekee saman asian: se avaa valikon. Alias `/checkpoint` johtaa samaan paikkaan. Kumpi tapa on kätevämpi, riippuu tottumuksista. Käytän `Esc Esc` -yhdistelmää: se on nopeampi, eikä käsiä tarvitse irrottaa näppäimistöltä. ## Rewind-valikon 6 tilaa: minkä valitset ja milloin?
Tärkeimmät kohdat Kun olet valinnut valikosta palautuskohdan, näkyviin tulee toinen valikko, jossa on kuusi tilaa. Kolme palauttaa tilan (`Restore code and conversation`, `Restore conversation`, `Restore code`), kaksi tiivistää historiaa (`Summarize from here`, `Summarize up to here`) ja yksi peruuttaa toiminnon (`Never mind`). Tavallisin tilanne – ”palauta sekä koodi että keskustelu” – vastaa ensimmäistä vaihtoehtoa.
Valitse luettelosta kohta, niin pääset toimintovalikkoon. Siinä on kuusi eri tavalla toimivaa vaihtoehtoa. **Tilojen täydellinen taulukko:** | Tila | Mitä se tekee | Milloin valita | |----|----|----| | `Restore code and conversation` | Palauttaa sekä tiedostot että keskusteluhistorian valittuun kohtaan | Tavallisin tilanne: Claude lähti väärään suuntaan, ja haluan aloittaa alusta oikealla muotoilulla | | `Restore conversation` | Kumoaa vain keskusteluhistorian muutokset; tiedostot jäävät nykyiselleen | Koodi on hyvä, mutta keskustelu ajautui väärille urille; muotoilen uudelleen tästä kohdasta ja säilytän nykyiset muutokset | | `Restore code` | Kumoaa tiedostomuutokset; keskustelu säilyy ennallaan | Osa Clauden muutoksista oli tarpeettomia, mutta tarvitsen edelleen keskustelun kontekstin (esimerkiksi koska sovimme seuraavista vaiheista) | | `Summarize from here` | Tiivistää kaiken valitun kohdan JÄLKEEN tapahtuneen yhteenvedoksi. Ei koske tiedostoihin | Pitkä virheenjäljitysistunto täytti kontekstin; haluan vapauttaa tilaa mutta säilyttää alkuperäiset ohjeet kokonaisina | | `Summarize up to here` | Tiivistää kaiken ennen valittua kohtaa yhteenvedoksi. Ei koske tiedostoihin | Pitkää aloitusohjeistusta seurasi tarkka tehtävä – tiivistämme ohjeistuksen yhdeksi viestiksi ja jätämme viimeaikaisen työn ennalleen | | `Never mind` | Sulkee valikon tekemättä muutoksia | Muutin mieleni | `Summarize up to here` tuli Claude Codeen versioissa v2.1.139–v2.1.142, jotka julkaistiin 11.–15. toukokuuta 2026, viikolla 20:

Voit tiivistää varhaisen kontekstin Rewind-valikossa valitsemalla ”Summarize up to here”.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
`Restore`- ja `Summarize`-toimintojen ero on perustavanlaatuinen. Restore palauttaa aiempaan tilaan ja kumoaa kaiken valitun kohdan jälkeen tapahtuneen. Summarize ei kumoa mitään, vaan ainoastaan tiivistää: alkuperäiset viestit säilyvät istunnon litteroinnissa viitteenä, mutta aktiivisessa kontekstissa on vain yhteenveto. Käytä Restore-toimintoa, kun haluat, että ”tätä ei olisi koskaan tapahtunut”. Käytä Summarize-toimintoa, kun haluat ”säilyttää tämän mutta olla käyttämättä siihen kontekstitilaa”. `Restore conversation`- tai `Summarize from here` -toiminnon jälkeen valitun kehotteen alkuperäinen teksti palautuu syötekenttään. Voit muokata sitä ja lähettää uudelleen. `Summarize up to here` -toiminnon jälkeen syötekenttä on tyhjä ja olet edelleen keskustelun lopussa. ## Mitä muutoksia /rewind EI kumoa?
Tärkeimmät kohdat `/rewind` seuraa vain muutoksia, jotka Claude tekee omilla tiedostojen muokkaustyökaluillaan. Se ei näe eikä voi palauttaa mitään muuta. Näkymättömiä muutoksia on kolmenlaisia: bash-komennot (rm, mv, cp), ulkoiset muokkaukset (manuaaliset muokkaukset IDE:ssä ja muiden istuntojen muutokset) sekä tiedostojen ulkopuoliset toiminnot (tietokantamigraatiot, git push, etä-API-kutsut).
Tämä on tärkein rajoitus, johon ihmiset törmäävät: `/rewind` näyttää vihreän valintamerkin ja ilmoittaa ”palautus onnistui”, mutta projekti on silti rikki, koska Claude teki muutakin kuin muutti tiedostoja. Katsotaanpa näitä kolmea tapausta. **1. Bash-komentoja ei seurata.** Jos Claude suorittaa vuoron aikana komennon `rm file.txt` tai `mv old.txt new.txt`, muutokset eivät sisälly tarkistuspisteeseen. Anthropicin dokumentaatio sanoo nimenomaisesti:

Tarkistuspisteet eivät seuraa bash-komennoilla muutettuja tiedostoja. Jos Claude Code esimerkiksi suorittaa komennot rm file.txt, mv old.txt new.txt tai cp source.txt dest.txt, tiedostomuutoksia ei voi kumota rewind-toiminnolla.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Tämä tarkoittaa, ettei `/rewind` palauta kaikkea, jos Claude poistaa, siirtää tai kopioi tiedoston itse bash-työkalulla. `git checkout` tai palautus varmuuskopiosta voi auttaa, mutta se vaatii enemmän kuin kahden näppäimen painalluksen. **2. Ulkoisia muokkauksia ei havaita.** Jos avaat tiedoston manuaalisesti VS Codessa ja muokkaat sitä tai toinen Claude-istunto muuttaa samoja tiedostoja samaan aikaan, ensimmäinen istunto ei näe näitä muutoksia. Tarkistuspiste otetaan, kun Claude päättää vuoron nykyisessä istunnossa. Vuorojen välillä tapahtuva ei kuulu sen vastuulle. **3. Tiedostojen ulkopuolisia toimintoja ei kateta lainkaan.** `npx prisma migrate dev` -komennolla tehty Prisma-migraatio muutti tietokannan skeemaa. `/rewind` ei kumoa sitä, koska tietokanta on projektin tiedostojärjestelmän ulkopuolella. Sama pätee force-pushiin kohteeseen `origin/main`: commit siirtyi etäpalvelimelle, eikä tarkistuspiste palauta sitä. Etä-API-kutsu, joka veloitti rahaa tai poisti tietueen, voidaan kumota vain API:n omilla mekanismeilla. **Sääntö:** Jos tehtävä vaikuttaa johonkin projektitiedostojen ulkopuolella – tietokantamigraatioihin, git pushiin tai etä-API-kutsuihin – valmistele erillinen palautusstrategia kullekin ulkoiselle vaikutukselle. `/rewind` kattaa vain paikallisen tiedostohistorian nykyisessä istunnossa. ## /rewind ja git: miten ne eroavat, ja miksi tarvitset molempia?
Tärkeimmät kohdat `/rewind` on paikallinen palautus yhdessä Claude Code -istunnossa. Se tallentaa inkrementaalisia tilannekuvia enintään 30 päivän ajan, enintään 100 kutakin istuntoa kohden. git on pitkäaikainen, tiimin kanssa jaettu projektihistoria, jossa on haarat, yhdistämisristiriidat ja etärepositorio. Kumpikaan ei korvaa toista. Hyvä käytäntö on tehdä `git commit` jokaisessa loogisessa virstanpylväässä ja käyttää `/rewind`-toimintoa commitien välillä.
Anthropicin dokumentaatio kuvaa tämän rinnakkaisuuden suoraan:

Tarkistuspisteet on suunniteltu nopeaan istuntokohtaiseen palautukseen. Jatka versionhallintajärjestelmän (esimerkiksi Gitin) käyttöä commitien, haarojen ja pitkäaikaisen historian hallintaan. Tarkistuspisteet täydentävät tavallista versionhallintaa, mutta eivät korvaa sitä. Ajattele tarkistuspisteitä ”paikallisena kumoamisena” ja Gitiä ”pysyvänä historiana”.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Erot yhdessä taulukossa: | Ominaisuus | /rewind | git | |----|----|----| | Tarkkuustaso | Jokainen keskusteluvuoro | Jokainen commit | | Tallennus | Enintään 30 päivää, enintään 100 istuntoa kohden, paikallisesti hakemistossa `~/.claude/file-history/` | Pysyvästi repositorion `.git/`-hakemistossa ja etäpalvelimella | | Mitä se seuraa | Clauden omilla työkaluillaan tekemät muutokset | Kaikki commit-toiminnolla tallennetut muutokset | | Mitä se EI seuraa | Bash, ulkoiset muokkaukset, migraatiot, push | Commitoimattomat muutokset | | Komento | Clauden sisäinen komento | Ulkoinen versionhallintajärjestelmä | | Kumoaa keskustelun | Kyllä | Ei | | Toimii istuntojen välillä | Vain saman istunnon sisällä | Kaikkialla | Yhdistelmä on yksinkertainen: aina kun pääset tilaan, jossa ”tämä toimii enkä halua menettää sitä”, tee `git commit`. Käytä commitien välillä `/rewind`-toimintoa – se on välitön, ei vaadi commit-viestiä eikä täytä git-historiaa välitiloilla. Kun työ on valmis, tee commit, mieluiten merkityksellinen ja atominen. ## Miksi yksi /rewind ei kata koko tehtävää? Kumoaminen on yksi **kontekstinhallinnan** osa-alue. Kun hallitset istunnon kontekstia (milloin commitoida, milloin painaa `/rewind`, mitä sääntöjä lisätä `CLAUDE.md`-tiedostoon), Claude toimii ennakoitavasti eikä tuhoa projektia tai hukkaa työtä. ## Miksi `git reset --hard` on vaarallinen, kun pyydät Claudea palauttamaan aiemman tilan?
Tärkeimmät kohdat Luonnollisella kielellä ”palauta” tarkoittaa ”katso historiaa”, ei ”tuhoa se”; Clauden pitäisi ehdottaa oletusarvoisesti `git checkout`-komentoa, ei `reset --hard` -komentoa; suojaus määritetään tiedostossa CLAUDE.md.
Pyyntö ”tallenna nykyinen tila ja palauta viimeisimpään pushiin” voi johtaa näihin komentoihin: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Ensimmäinen komento oli oikein: se tallensi committaamattomat muutokset stashiin. Toinen oli tuhoisa: se kirjoitti haaran uudelleen commit-tilaan `35eb731`, ja kaikki sen ja `882e618`-commitin väliset commitit jäivät irralleen. Oletusarvoisesti irralliset commitit säilyvät hakemistossa `.git/objects/`, kunnes `git gc` suoritetaan. Tämä tapahtuu yleensä automaattisesti kahden viikon sisällä. Jos et kuitenkaan tiennyt silloin, mitä tehdä, aika oli jo käymässä vähiin. Logiikka on yksinkertainen: luonnollisella kielellä ”palauta”, ”mene takaisin”, ”palauta ennalleen”, ”revertoi” ja ”kumoa” tarkoittavat ”katso taaksepäin” tai ”palaa turvalliseen paikkaan”. Ne eivät tarkoita ”tuhoa historia”. Komento `git reset --hard` tuhoaa sen: se kirjoittaa haaran uudelleen ja poistaa commitit niistä, joihin pääsee HEADin kautta. Turvallinen vaihtoehto on `git checkout `, joka luo detached HEADin ja antaa sinun tarkastella vanhaa tilaa koskematta haaroihin. Tärkein käytännön neuvo on tehdä nykyisestä tilasta `git commit` ennen merkittävää tehtävää, etenkin ennen useiden tiedostojen refaktorointia. Yksi commit mahdollistaa Claude-mokan korjaamisen yhdellä `git checkout .` -komennolla työtä menettämättä. ## Miten git reflog pelastaa tuhoavan resetin jälkeen?
Tärkeimmät kohdat `git reflog` näyttää kaikkien HEADin liikkeiden paikallisen historian repositoriossa – myös commitit, jotka on poistettu `git reset --hard` -komennolla tai force-pushilla. Jokainen liike tallennetaan oletusarvoisesti 90 päiväksi. Jos Claude (tai sinä tai joku muu) tuhosi commitit tuhoavalla komennolla, `git reflog` näyttää niiden hashit ja voit palauttaa haaran komennolla `git reset --hard `.
Suorita tuhoavan resetin jälkeen heti `git reflog` -komento: ```bash git reflog ``` Tuloste näyttää tältä: ``` 35eb731 HEAD@{0}: reset: moving to 35eb731 882e618 HEAD@{1}: commit: middleware refactoring complete d63695e HEAD@{2}: commit: leaveRemove method finalized 1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled 35eb731 HEAD@{4}: pull origin main ``` `HEAD@{1}`–`HEAD@{3}` ovat juuri ne ”tuhotut” commitit. Ne eivät ole kadonneet gitin paikallisesta objektivarastosta; niihin ei vain enää pääse haaran kautta. Palauta ne näin: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Sen jälkeen haara sisältää jälleen koko historian katastrofiin asti. **Reflogin rajoitukset:** 1. **Vain paikallinen.** Reflog tallennetaan tiedostoon `.git/logs/HEAD`, eikä sitä ole etärepositoriossa. Jos teet force-pushin ja poistat sitten paikallisen repositoriokopiosi, reflog katoaa hakemiston mukana. 2. **Oletusarvoisesti 90 päivää.** git gc voi poistaa vanhempia merkintöjä. Voit määrittää säilytysajan komennolla `git config gc.reflogExpire 200.days.ago`. 3. **Ei kata sitä, mikä ei koskaan ollut HEADissä.** Jos commit oli vain stashissa ja stash tuhottiin, reflog näyttää vain stashin viimeisimmän tilan, ei sen sisäistä historiaa. **Tiimin sääntö:** Älä koskaan suorita `git gc --aggressive` -komentoa heti katastrofin jälkeen. Tutki tilanne ensin reflogilla ja palauta työ; tee kaikki muu vasta sen jälkeen. Älä myöskään poista paikallista repositoriokloonia ennen kuin olet varma, että kaikki tarvitsemasi on pushattu. ## Miten suojaat projektin tuhoavilta git-komennoilta CLAUDE.md:n avulla?
Tärkeimmät kohdat Lisää projektin `CLAUDE.md`-tiedostoon ohjeistus, joka määrittää, mitä git-komentoja Claude saa suorittaa itsenäisesti, mitkä vaativat nimenomaisen vahvistuksen ja mitkä ovat kiellettyjä ilman käyttäjän täsmällistä ilmausta. Claude käsittelee CLAUDE.md:tä projektin järjestelmäkehotteena ja noudattaa näitä sääntöjä oletusarvoisesti. Näin yhdestä ”vaarallisesta” promptista tulee kaksi turvallista komentoa.
Haavoittuvuus on se, ettei Claudella ole oletusarvoisesti suojaavaa kontekstia. Se tulkitsee ”palauta” komennoksi `git reset --hard`, koska se on teknisesti pätevä tapa. Lisää suojaus tiedostoon `CLAUDE.md`, projektin järjestelmäkehote-tiedostoon. **Minimisääntö** (lisää `CLAUDE.md`-tiedostoosi): ```markdown ## Git Safety Protocol - NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless I explicitly request these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work. - When I say "roll back", "go back", "restore", "revert", "undo" - interpret as REVIEW commands: use `git log`, `git diff`, `git checkout ` (creates detached HEAD), or `git stash` (preserves changes). - ALWAYS ask for confirmation before ANY command that: - Changes HEAD position to a different commit on a branch - Modifies commit history - Could lose uncommitted work - Includes flags --hard, --force, --aggressive - Before any destructive command, output a numbered comparison: - SAFE: use `git checkout ` to view temporarily - DESTRUCTIVE: use `git reset --hard` to permanently destroy - Wait for my explicit choice before executing. ``` **Laajennettu sääntö** tiimille (lisää repositorion juuren `CLAUDE.md`-tiedostoon): ```markdown ## Git Workflow Rules - Tee commit jokaisessa toimivassa välitavoitteessa. Tarkista ennen WIP-committia `git status` ja `git diff`, lisää vaiheistukseen vain nimenomaisesti katselmoidut nimetyt tiedostot komennolla `git add -- path/to/file` ja tarkista vaiheistettu diff ennen committia. Ajastin muistuttaa tarkistamaan työn; se ei valtuuta lisäämään koko työpuuta. - Never use `git add .` or `git add -A` for commits by Claude. Only specify files by name, after `git status` + `git diff`. - Before `git push --force` to main—stop and ask me. In feature branches, force-push cautiously, only if you're sure I'm willing to lose the previous version. - When resolving merge conflicts, never choose "ours" or "theirs" immediately—show me both versions first, then I'll decide. - `.gitignore` must contain `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. If they're missing, add them. ``` Kun nämä osiot on lisätty, seuraava pyyntö ”palauta viimeisimpään pushiin” saisi aikaan tällaisen vastauksen: > Näen 3 committaamatonta tiedostoa ja 4 committia viimeisimmän pushin jälkeen. Kaksi vaihtoehtoa: > > 1. TURVALLINEN: luon haaran `view-last-push` komennolla `git checkout `. Säilytän kaiken työn mutta näytän väliaikaisesti pushin tilan. > 2. TUHOAVA: `git reset --hard ` – tuhoan pysyvästi 4 committia ja committaamattomat muutokset. Ne voi palauttaa vain `git reflog`-toiminnolla 90 päivän kuluessa. Kumman valitset? Siinä on puolen minuutin keskustelu neljän tunnin menetetyn työn sijaan. ## Mitkä ovat Claude Coden 5 tapaa kumota muutoksia, ja miten valitset oikean?
Tärkeimmät kohdat Jos jokin menee pieleen, tarjolla on viisi hätätilan tasoa: `/rewind` (istunnon aikana), `git checkout .` (committaamattomat muutokset), `git checkout ` (paluu vanhaan committiin historiaa menettämättä), `git reset --hard ` (haaran siirtäminen taaksepäin ja sitä edeltävien commitien menettäminen) sekä `git reflog` + palautus (katastrofi, kaikki on kadonnut). Jokainen taso on edellistä raskaampi ja vaarallisempi.
Tilanteessa ”Claude rikkoi sen, minun on palautettava se heti” edetään näitä portaita alhaalta ylöspäin. Aloita aina tasolta 1. **Taso 1. `/rewind` – välitön kumoaminen istunnon aikana.** Paina `Esc Esc` tai kirjoita `/rewind`. Valitse rikkoutumista edeltävä kohta. Valitse tila (yleensä `Restore code and conversation`). Hetkeä myöhemmin olet palannut menneeseen ja voit aloittaa uudelleen. Kattaa 80% tilanteista, joissa ”Claude teki väärin”. **Taso 2. `git checkout .` – kumoa kaikki committaamattomat muutokset.** ```bash git diff # first see what actually changed git checkout . # undo all uncommitted changes in all files # or selectively: git checkout -- path/to/file.ts # only one file ``` Hyödyllinen, kun `/rewind` ei toiminut (esimerkiksi Claude muokkasi tiedostoja bashilla) tai kun muutokset täytyy kumota istuntohistorian ulkopuolelta. Kaikki committaamattomat muutokset katoavat pysyvästi. Jos saatat katua sitä, suorita ensin `git stash` (katso taso 2.5). **Taso 2.5. `git stash` – laita muutokset talteen.** ```bash git stash save "might still need this" # return to a clean state (without changes) # ... # if you change your mind—restore from stash: git stash pop ``` Hyvä kompromissi ”menetä ikuisesti” - ja ”jätä ennalleen” -vaihtoehtojen välillä. Stash säilyy paikallisena, kunnes se erikseen tyhjennetään. **Taso 3. `git checkout ` – palaa vanhaan committiin historiaa menettämättä.** ```bash git log --oneline # find the hash of the right commit, e.g. abc1234 git checkout abc1234 # detached HEAD—view without changing anything # like the state? create a branch from it: git checkout -b recovery abc1234 # return: git checkout main ``` Tämä on turvallinen väliaikainen paluu. Detached HEAD ei muuta haaraa; nykyinen työsi `main`-haarassa (tai siinä haarassa, jota käytit) säilyy ennallaan. Jos haluat jatkaa työskentelyä tästä tilasta, luo siitä haara. **Taso 4. `git reset --hard ` – siirrä haara takaisin tiettyyn kohtaan.** ⚠️ Tuhoava. Määritetyn hashin jälkeiset commitit jäävät irrallisiksi. ```bash git reflog # note the hash of the current state git reset --hard abc1234 # rewrite the branch # found a mistake? return through reflog: git reset --hard HEAD@{1} # to where you were before the reset ``` Käytä tätä vain, jos olet varma, ettet tarvitse kohdan jälkeisiä committeja. Tarkista aina `git reflog` ENNEN reset-komentoa, jotta tiedät, mihin voit palata, jos muutat mielesi. **Taso 5. `git reflog` + palautus – katastrofitilanne.** Joku (Claude, sinä tai kollega) on jo suorittanut `git reset --hard` -komennon tai force-pushannut ja pyyhkinyt työn. Mitä teet? ```bash git reflog # look for the last hash before the disaster git branch recovered HEAD@{N} # create a branch from it git checkout recovered # switch to it git diff main # compare with the current state git checkout main && git merge recovered # restore into main, if you're sure ``` Jos reflog on jo tyhjennetty (oletusarvoisesti 90 päivän jälkeen), viimeinen keino on `git fsck --lost-found`, joka näyttää irralliset commitit hakemistossa `.git/objects/`. Se on lähes arkeologiaa, mutta joskus se toimii. **Sääntö tason valintaan:** | Mitä tapahtui | Taso | |-----------------------------------------------|-----------------------------| | Claude kirjoitti 3 tiedostoa väärällä tavalla uudelleen | 1\. `/rewind` | | Kokeilin sitä, en pitänyt siitä, eikä istunnosta ole apua | 2\. `git checkout .` | | Rikkoin sen itse, en halua menettää työtä ja saatan palauttaa sen | 2.5. `git stash` | | Tein commitin; minun täytyy palata yhden commitin verran | 3\. `git checkout ` | | Olen varma, etten tarvitse edeltäviä committeja | 4\. `git reset --hard` | | Tuhoava komento on jo pyyhkinyt sen | 5\. `git reflog` | ## Miten suojaat projektin niin, ettei mitään tarvitse kumota?
Tärkeimmät kohdat Paras kumoaminen on se, jota ei tarvita. Kolme suojaussääntöä: tarkista edistyminen 30 minuutin välein ja committoi toimiva välitavoite lisäämällä vaiheistukseen nimenomaisesti vain katselmoidut polut; lisää tarvittavat `.claude/personal/`- ja `.env*`-rivit `.gitignore`-tiedostoon; tee suuret kokeilut erillisessä haarassa komennolla `git checkout -b experiment-`. Tämä pienentää commitoitujen tiedostojen palautusväliä. Ulkoiset järjestelmät ja commitoimaton työ tarvitsevat edelleen oman palautussuunnitelmansa.
**Sääntö 1. Tee commit 30 minuutin välein.** Älä odota, kunnes ”tehtävä on valmis”. Tee commit jokaisesta toimivasta välivaiheesta. Commit-viestit voivat olla mitä tahansa; tärkeintä on, että Claude (tai sinä) voi palata toimivaan tilaan yhdellä `git checkout` -komennolla. ```bash # at the beginning of a task git status # tarkista kaikki vaiheistetut ja vaiheistamattomat polut git diff # katselmoi muutokset # Korvaa esimerkkipolku oikealla katselmoimallasi tiedostolla. git add -- path/to/file.ts git diff --cached # varmista täsmälleen commitoitava sisältö git commit -m "wip: starting User schema migration" # after 30 minutes (or after the first working iteration) git status git diff git add -- path/to/file.ts # oikea katselmoitu polku, ei hakemistojokeria git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # at the end of the task—a meaningful commit git reset --soft HEAD~2 # combine the three wip commits into one git commit -m "feat(auth): add lastLoginAt field to User table" ``` Jos lisäät PostToolUse-muistutuksen, säilytä sama katselmointi ja nimenomaisten polkujen vaiheistussääntö. Älä muuta ajastinta tarkistamattomaksi automaatticommitiksi: muuten mukaan voi päätyä asiaan kuulumattomia muokkauksia tai jo vaiheistettuja tiedostoja. **Sääntö 2. `.gitignore` minimiin.** Nämä rivit kuuluvat projektin juureen: ```gitignore # secrets .env .env.local .env.*.local # local Claude Code settings (not pushed to the team repository) .claude/personal/ .claude/sessions/ .claude/file-history/ # dependencies and build node_modules/ dist/ .next/ build/ ``` Käytän `.claude/personal/`-hakemistoa omiin kokeiluihin ja muistiinpanoihin, joita ei saa sisällyttää jaettuun repositorioon. `.claude/sessions/`- ja `.claude/file-history/`-hakemistot ovat Claude Coden paikallista tallennustilaa. Ne eivät kuulu repositorioon, vievät paljon tilaa ja ovat sidottuja tiettyyn koneeseen. **Sääntö 3. Tee kokeilut erillisessä haarassa.** Jos tehtävä on suuri (10+ tiedoston refaktorointi, siirtyminen uuteen tietokantaan tai moduulin uudelleenkirjoitus), älä tee sitä päähaarassa: ```bash git checkout -b experiment/auth-rewrite # work, commit every 30 minutes # if it works: git checkout main git merge experiment/auth-rewrite # if it doesn't: git checkout main git branch -D experiment/auth-rewrite # delete the branch # that's it, the main branch is intact ``` Tämä yksinkertainen tapa muuttaa tilanteen ”Claude tuhosi projektin” tilanteeksi ”Claude tuhosi yhden haaran, poistin sen, ja aloitamme uudelleen”. **Sääntö 4. Käytä `git tag` -komentoa ennen vaarallisia toimintoja.** Luo tagi ennen tietokantamigraatiota, suurta refaktorointia tai riippuvuuden päivitystä: ```bash git tag pre-prisma-migration-v2 # work # something went wrong: git reset --hard pre-prisma-migration-v2 # or just take a look: git checkout pre-prisma-migration-v2 ``` Tagi on nimetty viite commitiin, jota et menetä edes reflogin siivouksessa. ## Mitä seuraavaksi: miten kumoaminen liittyy kontekstinhallintaan?
Tärkeimmät kohdat Kumoaminen ei ole erillinen taito, vaan osa Claude Code -istunnon kontekstinhallintaa. Kun tiedät, milloin painaa `/rewind`, milloin tehdä `git commit` ja milloin käyttää `git stash` -komentoa, hallitset kokonaisen työnkulun, et vain yhtä komentoa. Tämä kuuluu **Context Engineering** -kokonaisuuteen. Ilman sitä Claude toimii tavallisen avustajan tavoin; sen kanssa se toimii ennakoitavana työkaluna.
Nämä kolme kumoamisen tasoa ovat yhden taidon perusta: tiedät, miten tila palautetaan, kun jokin menee rikki. Taito on itsessään rajallinen. Yhdessä muiden kontekstinhallinnan työkalujen kanssa siitä tulee kuitenkin jotakin enemmän. Plan Mode ei anna kirjoittaa koodia heti: ensin tehdään suunnitelma, sitten pyydetään vahvistus ja vasta sen jälkeen toteutetaan. Tämä on ennaltaehkäisevää kumoamista: et kirjoita sellaista, joka pitäisi myöhemmin kumota, koska suunnitelma tarkastettiin etukäteen. Lue lisää oppaasta [Plan Mode Claude Codessa](https://ailoot.ai/blog/fi/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/fi/claude-md-template/) määrittää säännöt, joita Claude noudattaa oletusarvoisesti, mukaan lukien yllä käsitelty Git Safety Protocol. Se suojaa ennalta tuhoavilta komennoilta. [Second Brain](https://ailoot.ai/blog/fi/claude-code-second-brain/) antaa Claudelle projektimuistin istuntojen välillä: se tietää, millaista koodia sinulla on, mikä liiketoimintalogiikka on ja mistä aiemmin sovittiin. Mitä enemmän muistia, sitä epätodennäköisemmin se tekee väärin. [Skills ja subagentit](https://ailoot.ai/blog/fi/claude-code-skills-library/) ovat menetelmäsi koodina. Jos oikea git-työnkulku rakennetaan Skill-toimintoon, yksikään subagentti ei suorita `git reset --hard` -komentoa ilman vahvistusta. Kaikki tämä yhdessä on **Context Engineering**. Hallitse kontekstia ennen promptia, älä sen aikana. Lue lisää artikkelista [mitä kontekstinhallinta on](https://ailoot.ai/blog/fi/context-engineering/). Kumoaminen on viimeinen puolustuslinja. Plan Mode + CLAUDE.md + Second Brain + Skills ovat neljä ensimmäistä. Kun ne on otettu käyttöön, kumoamista tarvitaan harvoin ja se on nopeaa. Ilman niitä siitä tulee päivittäinen rituaali.
### Lähteet - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new) - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
Kumoaminen alkaa siitä, mihin suunnittelu päättyy. [Avaa Ailoot](https://ailoot.ai/). ## Kysymyksiä tästä oppaasta: Näin kumoat Claude Coden muutokset: /rewind ja git ### Pitäisikö WIP-tarkistuspisteessä käyttää git add . -komentoa? Ei. Suorita `git status` ja `git diff`, vaiheista vain katselmoimasi nimetyt tiedostot ja tarkista `git diff --cached` ennen committia. Määräaikainen tarkistuspiste ei valtuuta lisäämään asiaan kuulumattomia tai aiemmin vaiheistettuja muutoksia. ### Voiko /rewind kumota tietokantamigraation tai etä-API-toimen? Ei. Opas rajaa tarkistuspisteet istunnon tuettuihin tiedostomuokkauksiin. Tietokannan, etä-Gitin ja API:n vaikutukset tarvitsevat erilliset palautusvaiheet. Käytä Gitiä tai varmuuskopiota tiedostoihin, joita tarkistuspiste ei kata. ## Ailoot · Yritys ja sen projektisalkku Ailoot perustuu kertyneeseen toimintakokemukseen, laajaan asiakaskuntaan, vakaaseen palveluun ja jatkuvaan KPI-seurantaan. Yritys ja sen projektisalkku: miljoonia asiakkaita; kuukausittainen myynti miljardiluokassa. Ailoot hyödyntää tätä toimintakokemusta tarjotessaan API-yhteyden tekoälytoimintoihin asiakkaiden tuotteissa, agenteissa, sovelluksissa ja automaatioissa.