Näin kumoat Claude Coden muutokset: /rewind ja git

Käytännön tietoa Ailootin käytöstä on dokumentaatiossa.

Mitä kumoaminen Claude Codessa tarkoittaa, ja miksi kolme tasoa ei riitä?#

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:

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?#

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:

/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?#

Valitse luettelosta kohta, niin pääset toimintovalikkoon. Siinä on kuusi eri tavalla toimivaa vaihtoehtoa.

Tilojen täydellinen taulukko:

Summarize up to here tuli Claude Codeen versioissa v2.1.139–v2.1.142, jotka julkaistiin 11.–15. toukokuuta 2026, viikolla 20:

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ä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:

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?#

Anthropicin dokumentaatio kuvaa tämän rinnakkaisuuden suoraan:

Erot yhdessä taulukossa:

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?#

Pyyntö ”tallenna nykyinen tila ja palauta viimeisimpään pushiin” voi johtaa näihin komentoihin:

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 <commit>, 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?#

Suorita tuhoavan resetin jälkeen heti git reflog -komento:

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:

# 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?#

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):

## 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 <commit>` (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 <commit>` 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):

## 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 <last-push-hash>. Säilytän kaiken työn mutta näytän väliaikaisesti pushin tilan.
2. TUHOAVA: git reset --hard <last-push-hash> – 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?#

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.

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.

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 <commit> – palaa vanhaan committiin historiaa menettämättä.

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 <commit> – siirrä haara takaisin tiettyyn kohtaan.

⚠️ Tuhoava. Määritetyn hashin jälkeiset commitit jäävät irrallisiksi.

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?

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:

Miten suojaat projektin niin, ettei mitään tarvitse kumota?#

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.

# 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:

# 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:

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ä:

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?#

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.

CLAUDE.md määrittää säännöt, joita Claude noudattaa oletusarvoisesti, mukaan lukien yllä käsitelty Git Safety Protocol. Se suojaa ennalta tuhoavilta komennoilta.

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 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.

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.

Kumoaminen alkaa siitä, mihin suunnittelu päättyy.

Avaa Ailoot.