# Cara membatalkan perubahan dalam Claude Code: /rewind dan git > Mod rewind, batasan checkpoint, git checkout, stash, reflog dan perlindungan daripada arahan yang merosakkan. Lima cara untuk memulihkan keadaan. Source: https://ailoot.ai/blog/ms/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/ms/claude-code-undo-changes/ Language: ms Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-79df3dc59fcf2d87f325f813003444916f2d63bde6af395e98c39ad37f0e1508 [Maklumat praktikal tentang penggunaan Ailoot tersedia dalam dokumentasi](https://ailoot.ai/docs/). ## Apakah pembatalan dalam Claude Code, dan mengapa tiga tahap tidak mencukupi?
Perkara utama Pembatalan dalam Claude Code mempunyai tiga tahap: arahan terbina dalam `/rewind` (pemulihan segera dalam sesi), `git checkout` (kembali ke commit terakhir) dan `git reflog` (jaring keselamatan bencana jika seseorang menjalankan `git reset --hard`). Setiap tahap meliputi kelas ralatnya sendiri dan tidak melepasi batas tersebut. Jika anda hanya tahu tentang `/rewind`, anda tidak akan terlindung apabila kesilapan serius pertama berlaku.
Saya mengaktifkan `/rewind` pada minggu pertama menggunakan Claude Code, apabila ia merosakkan logik pengesahan projek saya dalam dua prompt. Saya buat rewind, menarik nafas lega dan meneruskan kerja. Sebulan kemudian, timbul situasi lain: saya sedang menulis migrasi skema, Claude membantu, saya membuat commit, bertukar branch—kemudian sedar saya terlupa satu langkah yang perlu. `/rewind` tidak membantu—sesi sudah berbeza. `git checkout` ke commit sebelumnya membantu. Sebulan selepas itu, saya tidak sengaja menyuruh ejen itu, “kembalikan semuanya ke push terakhir,” lalu ia menjalankan `git reset --hard`, memusnahkan tiga jam kerja. `git reflog` menyelamatkan saya—hash commit yang dimusnahkan masih ada. Tiga kisah ini menunjukkan tiga tahap perlindungan yang berfungsi dengan cara berbeza, menangani ralat yang berbeza dan semuanya diperlukan. Panduan ini menerangkan setiap tahap berserta arahan, batasan dan contoh, serta menunjukkan cara mengkonfigurasi projek lebih awal supaya Claude tidak merosakkannya pada kali pertama. **3 tahap pembatalan—apa dan bila:** | Tahap | Arahan | Meliputi | TIDAK meliputi | |----|----|----|----| | 1\. Dalam sesi | `/rewind` atau `Esc Esc` | Fail yang diubah oleh Claude melalui alatnya sendiri; sejarah perbualan | Arahan Bash, editor luaran, migrasi pangkalan data | | 2\. Sebelum commit | `git checkout .` atau `git stash` | Semua perubahan fail yang belum di-commit | Commit yang sudah dibuat | | 3\. Bencana | `git reflog` + `git reset --hard ` | Commit yang dimusnahkan oleh `reset --hard` atau force-push | Arahan Bash yang merosakkan (rm, migrasi pangkalan data) | Seterusnya, kita akan meneliti setiap tahap—apa yang perlu dilakukan, perangkapnya dan cara mengkonfigurasi semuanya supaya tiada apa-apa yang perlu dibatalkan kerana tiada apa-apa yang rosak. ## Bagaimanakah cara memanggil /rewind: arahan atau Esc-Esc?
Perkara utama Terdapat dua cara untuk membuka menu Rewind dalam Claude Code. Pertama, taip `/rewind` dalam medan input. Kedua, tekan `Esc` dua kali apabila medan input kosong. Jika terdapat teks dalam medan itu, ketukan dua kali pada Esc akan memadamkannya dahulu dan menyimpannya dalam sejarah input; ketukan dua kali sekali lagi akan membuka menu. Arahan `/rewind` mempunyai alias `/checkpoint`.
Selepas setiap respons, Claude secara automatik mengambil snapshot semua fail yang dieditnya dalam sesi tersebut. Snapshot disimpan dalam `~/.claude/file-history/{sessionId}/` dan dikekalkan sehingga 30 hari. Snapshot bersifat inkremental—hanya perbezaan antara keadaan disimpan, bukannya keseluruhan fail. Secara lalai, sehingga 100 snapshot disimpan bagi setiap sesi. Ini bermakna dalam kebanyakan projek sebenar, anda mempunyai sejarah lengkap semua perubahan Claude sepanjang hari kerja pada bila-bila masa. Untuk membuka menu rewind, tekan `Esc` dua kali apabila medan input kosong: ``` [input kosong] > _ [tekan Esc, Esc] Rewind ke mesej yang mana? 1. Cipta migrasi untuk jadual User (3 fail diubah) 2. Tambah medan lastLoginAt (1 fail diubah) 3. Tulis semula logik kebenaran (5 fail diubah) ... ``` Jika terdapat teks dalam medan input, ketukan dua kali pertama pada `Esc` akan memadamkannya dan menyimpannya dalam sejarah `Up`. Ini berguna apabila anda sudah mula menaip lalu menyedari bahawa anda perlu membuat rewind. Petikan daripada dokumentasi rasmi Anthropic:

Jika terdapat teks dalam medan prompt, ketukan dua kali pada Esc akan memadamkannya dahulu dan bukannya membuka menu. Teks yang dipadam disimpan dalam sejarah input, jadi anda boleh memulihkannya dengan anak panah atas selepas menu rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Arahan `/rewind` melakukan perkara yang sama—membuka menu. Terdapat alias `/checkpoint` yang membawa ke tempat yang sama. Kaedah yang lebih mudah bergantung pada kebiasaan. Saya menggunakan `Esc Esc`—lebih pantas dan tangan tidak perlu dialihkan daripada papan kekunci. ## 6 mod dalam menu Rewind: yang mana patut dipilih dan bila?
Perkara utama Selepas memilih titik rewind dalam menu Rewind, menu kedua dengan enam mod akan muncul. Tiga memulihkan keadaan (`Restore code and conversation`, `Restore conversation`, `Restore code`), dua memampatkan sejarah (`Summarize from here`, `Summarize up to here`) dan satu membatalkan tindakan (`Never mind`). Situasi paling lazim—“rewind kedua-dua kod dan perbualan”—ialah pilihan pertama.
Pilih satu titik dalam senarai dan anda akan sampai ke menu tindakan. Terdapat enam pilihan, setiap satunya melakukan perkara yang berbeza. **Jadual lengkap mod:** | Mod | Fungsinya | Bila patut dipilih | |----|----|----| | `Restore code and conversation` | Memulihkan kedua-dua fail dan sejarah perbualan ke titik yang dipilih | Situasi paling lazim: Claude tersasar dan saya mahu bermula semula dengan arahan yang betul | | `Restore conversation` | Membuat rewind pada sejarah perbualan sahaja; fail kekal seperti sekarang | Kod sudah baik, tetapi perbualan tersasar; saya akan merumuskan semula dari titik ini sambil mengekalkan perubahan semasa | | `Restore code` | Membuat rewind pada fail; perbualan kekal seperti sedia ada | Sesetengah perubahan Claude tidak diperlukan, tetapi saya masih perlukan konteks perbualan (contohnya, kami sudah bersetuju tentang langkah seterusnya) | | `Summarize from here` | Memampatkan segala-galanya SELEPAS titik yang dipilih menjadi ringkasan. Tidak menyentuh fail | Sesi penyahpepijatan yang panjang telah menggunakan konteks; saya perlu mengosongkan ruang sambil mengekalkan arahan awal sepenuhnya | | `Summarize up to here` | Memampatkan segala-galanya SEBELUM titik yang dipilih menjadi ringkasan. Tidak menyentuh fail | Terdapat taklimat awal yang panjang diikuti tugasan khusus—kita ringkaskan taklimat itu dalam satu mesej dan biarkan kerja terkini seperti sedia ada | | `Never mind` | Menutup menu tanpa perubahan | Saya berubah fikiran | Ciri `Summarize up to here` muncul dalam Claude Code v2.1.139-v2.1.142, yang dikeluarkan pada 11–15 Mei 2026, minggu ke-20:

Anda boleh memampatkan konteks awal melalui menu Rewind menggunakan 'Summarize up to here'.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
Perbezaan antara `Restore` dan `Summarize` adalah asas. Restore mengembalikan keadaan terdahulu dan membatalkan segala-galanya yang berlaku selepas titik yang dipilih. Summarize tidak membatalkan apa-apa; ia hanya memampatkan—mesej asal kekal dalam transkrip sesi untuk rujukan, tetapi hanya ringkasan yang kekal dalam konteks aktif. Gunakan restore apabila anda mahu keadaan menjadi “seolah-olah perkara ini tidak pernah berlaku.” Gunakan summarize apabila anda mahu “menyimpannya, tetapi tidak memenuhi ruang konteks.” Selepas `Restore conversation` atau `Summarize from here`, teks asal prompt yang dipilih akan kembali ke medan input—anda boleh mengeditnya dan menghantarnya semula. Selepas `Summarize up to here`, medan input kosong dan anda kekal di penghujung perbualan. ## Apakah perubahan yang TIDAK dibatalkan oleh /rewind?
Perkara utama `/rewind` hanya menjejaki perubahan yang dibuat oleh Claude melalui alat penyuntingan failnya sendiri. Ia tidak dapat melihat atau memulihkan apa-apa yang lain. Terdapat tiga jenis perubahan yang tidak kelihatan: arahan Bash (rm, mv, cp), suntingan luaran (suntingan manual anda dalam IDE, perubahan daripada sesi lain) dan operasi di luar fail (migrasi pangkalan data, git push, panggilan API jauh).
Inilah batasan utama yang dihadapi orang: `/rewind` menunjukkan tanda semak hijau dan menyatakan “rewind berjaya,” tetapi projek masih rosak kerana Claude mengubah lebih daripada fail sahaja. Mari lihat tiga kes tersebut. **1. Arahan Bash tidak dijejaki.** Jika Claude menjalankan `rm file.txt` atau `mv old.txt new.txt` dalam satu giliran, perubahan itu tidak disertakan dalam checkpoint. Dokumentasi Anthropic menyatakan dengan jelas:

Checkpointing tidak menjejaki fail yang diubah melalui arahan Bash. Contohnya, jika Claude Code menjalankan rm file.txt, mv old.txt new.txt atau cp source.txt dest.txt, perubahan fail ini tidak boleh dibatalkan melalui rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Ini bermakna jika Claude memadamkan, memindahkan atau menyalin fail sendiri menggunakan alat Bash, `/rewind` tidak akan memulihkan semuanya. `git checkout` atau memulihkan daripada sandaran mungkin membantu, tetapi proses itu memerlukan lebih daripada menekan dua kekunci. **2. Suntingan luaran tidak dikesan.** Jika anda membuka fail secara manual dalam VS Code dan mengedit sesuatu, atau sesi Claude kedua mengubah fail yang sama secara serentak, sesi pertama tidak dapat melihat perubahan tersebut. Snapshot checkpoint diambil apabila Claude menamatkan satu giliran dalam sesi semasa. Perkara yang berlaku antara giliran berada di luar tanggungjawabnya. **3. Operasi di luar fail langsung tidak diliputi.** Migrasi Prisma yang digunakan melalui `npx prisma migrate dev` mengubah skema pangkalan data—`/rewind` tidak akan membatalkannya kerana pangkalan data berada di luar sistem fail projek. Force-push ke `origin/main` juga sama: commit dihantar ke pelayan jauh dan checkpoint tidak akan mengembalikannya. Panggilan API jauh yang mengenakan caj atau memadam rekod hanya boleh dibatalkan melalui mekanisme API itu sendiri. **Peraturan:** Jika tugasan menjejaskan apa-apa di luar fail projek—migrasi pangkalan data, git push, API jauh—sediakan strategi rollback yang berasingan untuk setiap kesan luaran. `/rewind` hanya merangkumi sejarah fail setempat dalam sesi semasa. ## /rewind berbanding git: apakah perbezaannya dan mengapa anda perlukan kedua-duanya?
Perkara utama `/rewind` ialah rollback setempat dalam satu sesi Claude Code. Ia menyimpan snapshot inkremental sehingga 30 hari, maksimum 100 bagi setiap sesi. git ialah sejarah projek jangka panjang yang dikongsi bersama pasukan, dengan branch, konflik merge dan repositori jauh. Satu tidak menggantikan yang lain. Amalan terbaik ialah membuat `git commit` pada setiap pencapaian logik dan menggunakan `/rewind` antara commit.
Dokumentasi Anthropic menyatakan gandingan ini secara langsung:

Checkpoint direka untuk pemulihan pantas pada peringkat sesi. Untuk commit, branch dan sejarah jangka panjang, terus gunakan sistem kawalan versi (contohnya, Git). Checkpoint melengkapi kawalan versi biasa, tetapi tidak menggantikannya. Anggap checkpoint sebagai 'undo setempat' dan Git sebagai 'sejarah kekal'.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Perbezaannya dalam satu jadual: | Parameter | /rewind | git | |----|----|----| | Kehalusan | Setiap giliran dalam perbualan | Setiap commit | | Storan | Sehingga 30 hari, sehingga 100 bagi setiap sesi, secara setempat dalam `~/.claude/file-history/` | Secara kekal, dalam `.git/` repositori dan pada pelayan jauh | | Perkara yang dijejaki | Suntingan Claude melalui alatnya sendiri | Semua perubahan yang di-commit | | Perkara yang TIDAK dijejaki | Bash, suntingan luaran, migrasi, push | Perubahan yang belum di-commit | | Arahan | Arahan dalam Claude | Sistem kawalan versi luaran | | Membuat rewind pada perbualan | Ya | Tidak | | Berfungsi merentas sesi | Hanya dalam sesi yang sama | Di mana-mana | Gandingannya mudah: setiap kali anda mencapai keadaan “ini berfungsi dan saya tidak mahu kehilangannya,” buat `git commit`. Antara commit, gunakan `/rewind`—ia segera, tidak memerlukan mesej commit dan tidak memenuhi sejarah git dengan keadaan perantaraan. Apabila kerja selesai, buat commit—sebaik-baiknya commit yang bermakna dan atomik. ## Mengapa satu /rewind tidak meliputi keseluruhan tugasan? Pembatalan ialah salah satu kes **kejuruteraan konteks**. Urus konteks sesi (bila hendak membuat commit, bila hendak menekan `/rewind`, peraturan apa yang perlu dimasukkan ke dalam `CLAUDE.md`) dan anda akan mendapat Claude yang boleh dijangka, yang tidak memusnahkan projek atau kehilangan kerja. ## Mengapakah `git reset --hard` berbahaya apabila anda meminta Claude supaya “undur”?
Perkara utama Dalam bahasa semula jadi, “undur” bermaksud “lihat sejarah,” bukan “musnahkannya”; Claude sepatutnya menawarkan `git checkout` secara lalai, bukannya `reset --hard`; perlindungan dikonfigurasikan dalam CLAUDE.md.
Permintaan supaya “menyimpan keadaan semasa dan kembali ke push terakhir” boleh membawa kepada arahan ini: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Arahan pertama betul—ia menyimpan perubahan yang belum di-commit dalam stash. Arahan kedua bersifat merosakkan: ia menulis semula branch kepada commit `35eb731`, lalu semua commit antara commit itu dengan `882e618` menjadi yatim. Secara lalai, commit yatim kekal dalam `.git/objects/` sehingga `git gc` dijalankan, yang biasanya berlaku secara automatik dalam tempoh dua minggu. Tetapi jika anda tidak tahu apa yang perlu dilakukan pada saat itu, masa sudah mula menentang anda. Logiknya mudah: dalam bahasa semula jadi, “undur,” “kembali,” “pulihkan,” “revert” dan “batalkan” bermaksud “lihat semula” atau “kembali ke tempat yang selamat.” Itu tidak bermaksud “musnahkan sejarah.” Arahan `git reset --hard` memusnahkannya—ia menulis semula branch dan mengeluarkan commit yang tidak lagi boleh dicapai melalui HEAD. Alternatif yang selamat ialah `git checkout `, yang mencipta detached HEAD dan membolehkan anda melihat keadaan lama tanpa menyentuh branch. Kesimpulan praktikal utama ialah membuat `git commit` bagi keadaan semasa sebelum sebarang tugasan besar, khususnya sebelum memfaktorkan semula berbilang fail. Satu commit menukarkan kesilapan Claude menjadi satu arahan `git checkout .` tanpa kehilangan kerja. ## Bagaimanakah git reflog menyelamatkan anda selepas reset yang merosakkan?
Perkara utama `git reflog` menunjukkan sejarah setempat semua pergerakan HEAD dalam repositori—termasuk commit yang dibuang melalui `git reset --hard` atau force-push. Setiap pergerakan disimpan selama 90 hari secara lalai. Jika Claude (atau anda atau orang lain) memusnahkan commit dengan arahan yang merosakkan, `git reflog` akan menunjukkan hash-nya, dan anda boleh memulihkan branch dengan `git reset --hard `.
Selepas reset yang merosakkan, segera jalankan `git reflog`: ```bash git reflog ``` Outputnya kelihatan begini: ``` 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}` hingga `HEAD@{3}` ialah commit yang “dimusnahkan” itu. Commit tersebut tidak hilang daripada stor objek setempat git; ia cuma tidak lagi boleh dicapai melalui branch. Untuk memulihkannya: ```bash # cipta branch daripada commit “dimusnahkan” yang terakhir git branch recovered-work 882e618 # atau beralih terus kepadanya git reset --hard 882e618 ``` Selepas itu, branch tersebut sekali lagi mengandungi semua sejarah sehingga bencana itu. **Batasan reflog:** 1. **Setempat sahaja.** Reflog disimpan dalam `.git/logs/HEAD`; ia tiada dalam repositori jauh. Jika anda melakukan force-push kemudian memadam salinan repositori setempat, reflog akan hilang bersama folder itu. 2. **90 hari secara lalai.** Entri yang lebih lama mungkin dibuang oleh git gc. Anda boleh mengkonfigurasikannya dengan `git config gc.reflogExpire 200.days.ago`. 3. **Tidak meliputi perkara yang tidak pernah berada dalam HEAD.** Jika commit hanya berada dalam stash dan stash itu dimusnahkan, reflog hanya akan menunjukkan keadaan stash yang terkini, bukannya sejarah dalamannya. **Peraturan untuk pasukan:** jangan sekali-kali menjalankan `git gc --aggressive` sejurus selepas bencana. Siasat dahulu dengan reflog dan lakukan pemulihan; hal lain boleh dibuat kemudian. Dan jangan padam klon repositori setempat sehingga anda pasti semua yang diperlukan telah di-push. ## Bagaimanakah cara melindungi projek daripada arahan git yang merosakkan melalui CLAUDE.md?
Perkara utama Dalam `CLAUDE.md` projek, tambah blok arahan yang mentakrifkan arahan git yang boleh dijalankan Claude sendiri, arahan yang memerlukan pengesahan jelas dan arahan yang dilarang tanpa frasa tepat daripada pengguna. Claude menganggap CLAUDE.md sebagai prompt sistem projek dan mengikut peraturan ini secara lalai. Ini menukarkan satu prompt “berbahaya” menjadi dua arahan yang selamat.
Kelemahannya ialah Claude tidak mempunyai konteks perlindungan secara lalai. Ia mentafsir “undur” sebagai `git reset --hard` kerana dari sudut teknikal, itu satu kaedah yang sah. Letakkan perlindungan dalam `CLAUDE.md`—fail prompt sistem projek. **Peraturan minimum** (masukkan ke dalam `CLAUDE.md`): ```markdown ## Protokol Keselamatan Git - JANGAN SEKALI-KALI menjalankan arahan git yang merosakkan (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) melainkan saya meminta tindakan ini secara jelas. Mengambil tindakan merosakkan tanpa kebenaran tidak membantu dan boleh menyebabkan kerja hilang. - Apabila saya berkata "undur", "kembali", "pulihkan", "revert" atau "batalkan"—tafsirkannya sebagai arahan SEMAKAN: gunakan `git log`, `git diff`, `git checkout ` (mencipta detached HEAD) atau `git stash` (mengekalkan perubahan). - SENTIASA minta pengesahan sebelum MANA-MANA arahan yang: - Mengubah kedudukan HEAD ke commit lain pada branch - Mengubah sejarah commit - Boleh menyebabkan kerja yang belum di-commit hilang - Mengandungi flag --hard, --force, --aggressive - Sebelum sebarang arahan yang merosakkan, keluarkan perbandingan bernombor: - SELAMAT: gunakan `git checkout ` untuk melihatnya buat sementara waktu - MEROSAKKAN: gunakan `git reset --hard` untuk memusnahkannya secara kekal - Tunggu pilihan saya yang jelas sebelum melaksanakannya. ``` **Peraturan lanjutan** untuk pasukan (tambah pada `CLAUDE.md` di akar repositori): ```markdown ## Peraturan Aliran Kerja Git - Buat commit pada setiap pencapaian yang berfungsi. Sebelum commit WIP, jalankan `git status` dan `git diff`, stage hanya fail bernama yang disemak secara jelas dengan `git add -- path/to/file`, kemudian periksa diff staged sebelum commit. Pemasa ialah peringatan untuk menyemak, bukan kebenaran untuk stage seluruh pepohon kerja. - Jangan sekali-kali gunakan `git add .` atau `git add -A` untuk commit oleh Claude. Nyatakan fail mengikut nama sahaja, selepas `git status` + `git diff`. - Sebelum `git push --force` ke main—berhenti dan tanya saya. Dalam branch ciri, lakukan force-push dengan berhati-hati dan hanya jika anda pasti saya sanggup kehilangan versi sebelumnya. - Semasa menyelesaikan konflik merge, jangan sekali-kali terus memilih "ours" atau "theirs"—tunjukkan kedua-dua versi kepada saya dahulu, kemudian saya akan membuat keputusan. - `.gitignore` mesti mengandungi `.env*`, `.claude/personal/`, `node_modules/` dan `dist/`. Jika tiada, tambahkannya. ``` Selepas blok ini ditambah, frasa “undur ke push terakhir” akan menghasilkan respons seperti ini: > Saya nampak 3 fail yang belum di-commit dan 4 commit sejak push terakhir. Ada dua pilihan: > > 1. SELAMAT: cipta branch `view-last-push` melalui `git checkout `—saya akan mengekalkan semua kerja, tetapi memaparkan keadaan push buat sementara waktu. > 2. MEROSAKKAN: `git reset --hard `—saya akan memusnahkan 4 commit dan perubahan yang belum di-commit secara kekal. Semuanya hanya boleh dipulihkan melalui `git reflog` dalam tempoh 90 hari. Yang mana satu anda pilih? Itu cuma setengah minit perbualan, bukannya empat jam kerja yang hilang. ## Apakah 5 cara untuk membatalkan perubahan dalam Claude Code dan bagaimana memilih cara yang betul?
Perkara utama Jika sesuatu berlaku, terdapat lima tahap tindakan: `/rewind` (dalam sesi), `git checkout .` (perubahan yang belum di-commit), `git checkout ` (kembali ke commit lama tanpa kehilangan sejarah), `git reset --hard ` (mengundurkan branch dan kehilangan commit selepasnya) dan `git reflog` + pemulihan (bencana, semuanya sudah hilang). Setiap tahap lebih berat dan berbahaya daripada sebelumnya.
Senario “Claude merosakkannya, saya perlu memulihkannya dengan segera” bergerak dari bawah ke atas tangga ini. Sentiasa mulakan pada tahap 1. **Tahap 1. `/rewind`—pembatalan serta-merta dalam sesi.** Tekan `Esc Esc` atau taip `/rewind`. Pilih titik sebelum kerosakan berlaku. Pilih mod (biasanya `Restore code and conversation`). Sesaat kemudian, anda kembali ke masa lalu dan boleh bermula semula. Meliputi 80% kes “Claude melakukan perkara yang salah”. **Tahap 2. `git checkout .`—batalkan semua perubahan yang belum di-commit.** ```bash git diff # mula-mula lihat apa yang benar-benar berubah git checkout . # batalkan semua perubahan yang belum di-commit dalam semua fail # atau pilih fail tertentu: git checkout -- path/to/file.ts # satu fail sahaja ``` Berguna apabila `/rewind` tidak berjaya (contohnya Claude menyentuh fail melalui Bash) atau apabila anda perlu membatalkan perubahan di luar sejarah sesi. Semua perubahan yang belum di-commit akan hilang secara kekal. Jika anda mungkin menyesal, jalankan `git stash` dahulu (lihat tahap 2.5). **Tahap 2.5. `git stash`—simpan perubahan di tepi.** ```bash git stash save "might still need this" # kembali kepada keadaan bersih (tanpa perubahan) # ... # jika berubah fikiran, pulihkan daripada stash: git stash pop ``` Kompromi yang baik antara “hilang selama-lamanya” dengan “biarkan sahaja”. Stash kekal setempat sehingga dipadamkan secara jelas. **Tahap 3. `git checkout `—kembali ke commit lama tanpa kehilangan sejarah.** ```bash git log --oneline # cari hash commit yang betul, contohnya abc1234 git checkout abc1234 # detached HEAD—lihat tanpa mengubah apa-apa # suka keadaan ini? cipta branch daripadanya: git checkout -b recovery abc1234 # kembali: git checkout main ``` Ini ialah “kembali sementara” yang selamat. Detached HEAD tidak mengubah branch; kerja semasa anda dalam `main` (atau branch yang sedang digunakan) kekal utuh. Jika mahu bekerja dengan keadaan ini, cipta satu branch. **Tahap 4. `git reset --hard `—undurkan branch ke satu titik.** ⚠️ Merosakkan. Commit selepas hash yang ditentukan menjadi yatim. ```bash git reflog # catat hash keadaan semasa git reset --hard abc1234 # tulis semula branch # jumpa kesilapan? kembali melalui reflog: git reset --hard HEAD@{1} # kembali ke tempat anda sebelum reset ``` Gunakan hanya jika anda pasti tidak memerlukan commit selepas titik itu. Dan sentiasa semak `git reflog` SEBELUM reset supaya anda tahu ke mana hendak kembali jika berubah fikiran. **Tahap 5. `git reflog` + pemulihan—senario bencana.** Seseorang (Claude, anda atau rakan sekerja) sudah menjalankan `git reset --hard` atau force-push lalu menghapuskan kerja. Apa yang perlu dilakukan? ```bash git reflog # cari hash terakhir sebelum bencana git branch recovered HEAD@{N} # cipta branch daripadanya git checkout recovered # beralih kepadanya git diff main # bandingkan dengan keadaan semasa git checkout main && git merge recovered # pulihkan ke main jika anda pasti ``` Jika reflog sudah dipadam (selepas 90 hari secara lalai), pilihan terakhir ialah `git fsck --lost-found`, yang akan memaparkan commit tergantung dalam `.git/objects/`. Ini hampir seperti kerja arkeologi, tetapi kadangkala berjaya. **Peraturan untuk memilih tahap:** | Perkara yang berlaku | Tahap | |-----------------------------------------------|-----------------------------| | Claude menulis semula 3 fail dengan cara yang salah | 1\. `/rewind` | | Saya mencubanya, tidak suka hasilnya dan sesi tidak membantu | 2\. `git checkout .` | | Saya merosakkannya secara manual, tidak sanggup kehilangannya dan mungkin mahu memulihkannya | 2.5. `git stash` | | Saya sudah membuat commit; perlu undur satu commit | 3\. `git checkout ` | | Saya pasti tidak memerlukan commit selepasnya | 4\. `git reset --hard` | | Sudah terhapus akibat arahan yang merosakkan | 5\. `git reflog` | ## Bagaimanakah cara melindungi projek supaya tiada apa-apa perlu dibatalkan?
Perkara utama Pembatalan terbaik ialah pembatalan yang tidak diperlukan. Tiga peraturan perlindungan: semak kemajuan setiap 30 minit dan commit pencapaian yang berfungsi dengan stage hanya laluan yang disemak secara jelas; masukkan baris `.claude/personal/` dan `.env*` yang diperlukan ke dalam `.gitignore`; jalankan eksperimen besar pada branch berasingan dengan `git checkout -b experiment-`. Ini mengecilkan jurang pemulihan bagi fail yang dikomit; sistem luaran dan kerja belum dikomit masih memerlukan pelan pemulihan sendiri.
**Peraturan 1. Buat commit setiap 30 minit.** Jangan tunggu sehingga “tugasan selesai.” Buat commit bagi setiap langkah perantaraan yang berfungsi. Mesej commit boleh apa-apa sahaja; perkara utama ialah Claude (atau anda) boleh kembali ke keadaan yang berfungsi dengan satu arahan `git checkout`. ```bash # pada permulaan tugas git status # inspect all staged and unstaged paths git diff # review the changes # Replace this example path with the actual file you reviewed. git add -- path/to/file.ts git diff --cached # verify exactly what will be committed git commit -m "wip: starting User schema migration" # selepas 30 minit (atau selepas iterasi pertama yang berfungsi) git status git diff git add -- path/to/file.ts # actual reviewed path, not a directory wildcard git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # pada penghujung tugas—commit yang bermakna git reset --soft HEAD~2 # gabungkan tiga commit wip menjadi satu git commit -m "feat(auth): add lastLoginAt field to User table" ``` Jika menambah peringatan PostToolUse, kekalkan peraturan semakan dan staging laluan jelas yang sama. Jangan tukarkan pemasa menjadi auto-commit tanpa pemeriksaan: suntingan tidak berkaitan atau fail yang sudah distage boleh termasuk dalam commit. **Peraturan 2. `.gitignore` minimum.** Baris ini diperlukan pada akar projek: ```gitignore # rahsia .env .env.local .env.*.local # tetapan Claude Code setempat (tidak dihantar ke repositori pasukan) .claude/personal/ .claude/sessions/ .claude/file-history/ # kebergantungan dan binaan node_modules/ dist/ .next/ build/ ``` Saya menyimpan folder `.claude/personal/` untuk eksperimen dan nota saya sendiri, yang tidak boleh disertakan dalam repositori kongsi. Folder `.claude/sessions/` dan `.claude/file-history/` ialah storan setempat Claude Code; kedua-duanya tidak sesuai dimasukkan ke dalam repositori, menggunakan banyak ruang dan terikat pada mesin tertentu. **Peraturan 3. Buat eksperimen pada branch berasingan.** Jika tugasnya besar (memfaktorkan semula 10+ fail, berpindah ke pangkalan data baharu, menulis semula modul), jangan lakukannya pada branch utama: ```bash git checkout -b experiment/auth-rewrite # bekerja dan buat commit setiap 30 minit # jika berjaya: git checkout main git merge experiment/auth-rewrite # jika tidak berjaya: git checkout main git branch -D experiment/auth-rewrite # padam branch # itu sahaja, branch utama kekal utuh ``` Tabiat mudah ini menjadikan “Claude memusnahkan projek” kepada “Claude memusnahkan satu branch, saya memadamkannya dan kita bermula semula.” **Peraturan 4. Sebelum operasi berbahaya, gunakan `git tag`.** Sebelum migrasi pangkalan data, pemfaktoran semula besar atau kemas kini kebergantungan, cipta tag: ```bash git tag pre-prisma-migration-v2 # bekerja # sesuatu tidak kena: git reset --hard pre-prisma-migration-v2 # atau sekadar lihat: git checkout pre-prisma-migration-v2 ``` Tag ialah penunjuk bernama kepada commit yang tidak akan hilang walaupun selepas pembersihan reflog. ## Seterusnya: bagaimanakah pembatalan berkaitan dengan kejuruteraan konteks?
Perkara utama Pembatalan bukan kemahiran yang berasingan, tetapi sebahagian daripada pengurusan konteks sesi Claude Code. Apabila anda tahu bila hendak menekan `/rewind`, bila hendak membuat `git commit` dan bila hendak menggunakan `git stash`, anda mengurus keseluruhan aliran kerja, bukan satu arahan sahaja. Ini sebahagian daripada **Context Engineering**. Tanpanya, Claude bertindak seperti pembantu biasa; dengannya, Claude menjadi alat yang boleh dijangka.
Tiga tahap pembatalan ini ialah asas bagi satu kemahiran: mengetahui cara memulihkan keadaan apabila berlaku kerosakan. Kemahiran itu sendiri agak khusus. Namun, apabila digabungkan dengan alat kejuruteraan konteks yang lain, ia menjadi sesuatu yang lebih besar. Plan Mode tidak membenarkan anda menulis kod dengan serta-merta—mula-mula ada pelan, kemudian pengesahan, dan selepas itu pelaksanaan. Ini ialah pembatalan pencegahan: anda tidak menulis sesuatu yang perlu dibatalkan kemudian kerana pelannya telah disemak lebih awal. Baca lebih lanjut dalam panduan tentang [Plan Mode dalam Claude Code](https://ailoot.ai/blog/ms/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/ms/claude-md-template/) menetapkan peraturan yang dihormati Claude secara lalai, termasuk Protokol Keselamatan Git yang dibincangkan di atas. Ini ialah perlindungan pencegahan terhadap arahan yang merosakkan. [Second Brain](https://ailoot.ai/blog/ms/claude-code-second-brain/) memberi Claude ingatan tentang projek antara sesi—ia tahu kod yang anda miliki, logik perniagaannya dan persetujuan yang dibuat sebelum ini. Semakin banyak ingatan, semakin kecil kemungkinan ia melakukan perkara yang salah. [Skills dan subejen](https://ailoot.ai/blog/ms/claude-code-skills-library/) ialah metodologi anda dalam bentuk kod. Jika aliran kerja git yang betul terbina dalam Skill, tiada subejen akan menjalankan `git reset --hard` tanpa pengesahan. Dan semua ini bersama-sama ialah **Context Engineering**. Urus konteks sebelum prompt, bukan semasa melaksanakannya. Baca lebih lanjut dalam [apakah context engineering](https://ailoot.ai/blog/ms/context-engineering/). Pembatalan ialah barisan pertahanan terakhir. Plan Mode + CLAUDE.md + Second Brain + Skills ialah empat barisan pertama. Apabila semuanya disediakan, pembatalan menjadi jarang dan pantas. Jika tidak, ia menjadi rutin harian.
### Sumber - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Minggu 20, 11-15 Mei 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)
Pembatalan bermula di tempat perancangan berakhir. [Buka Ailoot](https://ailoot.ai/). ## Soalan lazim: Cara membatalkan perubahan dalam Claude Code: /rewind dan git ### Patutkah checkpoint WIP menggunakan git add .? Tidak. Jalankan `git status` dan `git diff`, stage hanya fail bernama yang telah anda semak, kemudian periksa `git diff --cached` sebelum commit. Checkpoint berkala tidak membenarkan penyertaan perubahan tidak berkaitan atau yang telah distage sebelumnya. ### Bolehkah /rewind membatalkan migrasi pangkalan data atau tindakan API jauh? Tidak. Panduan mengehadkan checkpoint kepada suntingan fail sesi yang disokong. Kesan pangkalan data, Git jauh dan API memerlukan langkah pemulihan berasingan; gunakan Git atau sandaran untuk fail di luar liputan checkpoint. ## Ailoot · Syarikat dan portfolio projeknya Ailoot berteraskan pengalaman operasi yang mantap, pangkalan pelanggan yang besar, perkhidmatan yang stabil dan pemantauan KPI berterusan. Syarikat dan portfolio projeknya: jutaan pelanggan; jualan bernilai berbilion setiap bulan. Ailoot menggunakan pengalaman operasi ini untuk akses API kepada ciri AI dalam produk pelanggan, ejen, aplikasi dan automasi.