# Cara membatalkan perubahan di Claude Code: /rewind dan git > Mode rewind, keterbatasan checkpoint, git checkout, stash, reflog, dan perlindungan terhadap perintah destruktif. Lima cara untuk memulihkan keadaan. Source: https://ailoot.ai/blog/id/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/id/claude-code-undo-changes/ Language: id Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-49284815edd02a91a5aa68b0760df0653753ce54f98e9c112abbe67693f404f8 [Informasi praktis tentang penggunaan Ailoot tersedia di dokumentasi](https://ailoot.ai/docs/). ## Apa itu pembatalan di Claude Code, dan mengapa tiga level tidak cukup?
Poin utama Pembatalan di Claude Code memiliki tiga level: perintah bawaan `/rewind` (pemulihan instan dalam satu sesi), `git checkout` (memulihkan ke commit terakhir), dan `git reflog` (jaring pengaman untuk bencana jika seseorang menjalankan `git reset --hard`). Setiap level menangani kelas kesalahan masing-masing dan tidak mencakup hal di luar batasnya. Jika hanya mengetahui `/rewind`, Anda akan kerepotan saat terjadi kesalahan serius pertama.
Saya mengaktifkan `/rewind` pada minggu pertama menggunakan Claude Code, ketika alat itu merusak logika autentikasi proyek saya dalam dua prompt. Saya melakukan rewind, menarik napas lega, lalu melanjutkan. Sebulan kemudian, muncul situasi lain: saya sedang menulis migrasi skema, Claude membantu, saya membuat commit, berpindah cabang—lalu sadar bahwa saya lupa langkah penting. `/rewind` tidak membantu—sesinya sudah berbeda. `git checkout` ke commit sebelumnya berhasil. Sebulan setelah itu, saya tidak sengaja memberi tahu agen, “kembalikan semuanya ke push terakhir,” dan agen menjalankan `git reset --hard`, menghancurkan pekerjaan selama tiga jam. `git reflog` menyelamatkan saya—hash commit yang dihancurkan masih ada. Ketiga cerita itu menunjukkan tiga level perlindungan yang bekerja dengan cara berbeda, menangani kesalahan yang berbeda, dan semuanya diperlukan. Panduan ini menjelaskan setiap level beserta perintah, keterbatasan, dan contohnya, serta menunjukkan cara mengonfigurasi proyek terlebih dahulu agar Claude tidak merusaknya sejak awal. **3 level pembatalan—apa dan kapan:** | Level | Perintah | Mencakup | TIDAK mencakup | |----|----|----|----| | 1\. Dalam satu sesi | `/rewind` atau `Esc Esc` | File yang diubah Claude melalui alatnya sendiri; riwayat percakapan | Perintah Bash, editor eksternal, migrasi basis data | | 2\. Sebelum commit | `git checkout .` atau `git stash` | Semua perubahan file yang belum di-commit | Commit yang sudah dibuat | | 3\. Bencana | `git reflog` + `git reset --hard ` | Commit yang dihancurkan oleh `reset --hard` atau force-push | Perintah bash destruktif (rm, migrasi basis data) | Selanjutnya, kita akan membahas setiap level—apa yang harus dilakukan, jebakannya, dan cara mengonfigurasi semuanya agar tidak ada yang perlu dibatalkan karena tidak ada yang rusak. ## Bagaimana cara memanggil /rewind: perintah atau Esc-Esc?
Poin utama Ada dua cara untuk membuka menu Rewind di Claude Code. Cara pertama adalah mengetik `/rewind` di kolom input. Cara kedua adalah menekan `Esc` dua kali saat kolom input kosong. Jika ada teks di kolom tersebut, dua kali Esc pertama akan menghapusnya dan menyimpan isinya ke riwayat input; dua kali penekanan berikutnya akan membuka menu. Perintah `/rewind` memiliki alias `/checkpoint`.
Setelah setiap respons, Claude secara otomatis mengambil snapshot semua file yang dieditnya dalam sesi tersebut. Snapshot disimpan di `~/.claude/file-history/{sessionId}/` dan disimpan hingga 30 hari. Snapshot bersifat inkremental—hanya perbedaan antar-keadaan yang disimpan, bukan seluruh file. Secara default, hingga 100 snapshot disimpan per sesi. Artinya, di sebagian besar proyek nyata, kapan saja Anda memiliki riwayat lengkap semua perubahan Claude sepanjang hari kerja. Untuk membuka menu rewind, tekan `Esc` dua kali saat kolom input kosong: ``` [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) ... ``` Jika ada teks di kolom input, penekanan ganda `Esc` pertama akan menghapusnya dan menyimpannya dalam riwayat `Up`. Ini berguna saat Anda sudah mulai mengetik lalu sadar perlu melakukan rewind. Berikut kutipan dari dokumentasi resmi Anthropic:

Jika ada teks di kolom prompt, dua kali Esc akan terlebih dahulu menghapusnya, bukan membuka menu. Teks yang dihapus disimpan dalam riwayat input, sehingga Anda dapat memulihkannya dengan tombol panah atas setelah menu rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Perintah `/rewind` melakukan hal yang sama—membuka menu. Ada alias `/checkpoint` yang menuju ke tempat yang sama. Metode mana yang lebih nyaman bergantung pada kebiasaan. Saya menggunakan `Esc Esc`—lebih cepat dan tangan tidak perlu meninggalkan papan ketik. ## 6 mode di menu Rewind: mana yang harus dipilih, dan kapan?
Poin utama Setelah memilih titik rewind di menu Rewind, menu kedua akan muncul dengan enam mode. Tiga memulihkan keadaan (`Restore code and conversation`, `Restore conversation`, `Restore code`), dua meringkas riwayat (`Summarize from here`, `Summarize up to here`), dan satu membatalkan tindakan (`Never mind`). Skenario paling umum—“rewind kode dan percakapan sekaligus”—adalah opsi pertama.
Pilih satu titik dalam daftar, lalu Anda akan masuk ke menu tindakan. Ada enam item, masing-masing melakukan hal berbeda. **Tabel lengkap mode:** | Mode | Fungsinya | Kapan memilihnya | |----|----|----| | `Restore code and conversation` | Memulihkan file dan riwayat percakapan ke titik yang dipilih | Skenario paling umum: Claude mengambil arah yang salah, dan saya ingin memulai lagi dengan instruksi yang tepat | | `Restore conversation` | Hanya memundurkan riwayat percakapan; file tetap seperti sekarang | Kodenya sudah baik, tetapi percakapan melenceng; saya akan menyusun ulang kata-kata mulai dari titik ini sambil mempertahankan perubahan saat ini | | `Restore code` | Memundurkan file; percakapan tetap seperti sekarang | Sebagian perubahan Claude tidak diperlukan, tetapi saya masih memerlukan konteks percakapan (misalnya, kami sudah menyepakati langkah berikutnya) | | `Summarize from here` | Meringkas semua yang terjadi SETELAH titik yang dipilih. Tidak menyentuh file | Sesi debugging yang panjang menghabiskan konteks; saya perlu mengosongkan ruang sambil mempertahankan instruksi awal secara utuh | | `Summarize up to here` | Meringkas semua yang terjadi SEBELUM titik yang dipilih. Tidak menyentuh file | Ada pengarahan awal yang panjang, lalu tugas khusus—kita meringkas pengarahan itu menjadi satu pesan dan membiarkan pekerjaan terbaru seperti adanya | | `Never mind` | Menutup menu tanpa perubahan | Saya berubah pikiran | Fitur `Summarize up to here` muncul di Claude Code v2.1.139-v2.1.142, yang dirilis pada 11–15 Mei 2026, minggu ke-20:

Anda dapat meringkas konteks awal melalui menu Rewind menggunakan 'Summarize up to here'.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
Perbedaan antara `Restore` dan `Summarize` bersifat mendasar. Restore kembali ke keadaan sebelumnya dan membatalkan semua yang terjadi setelah titik yang dipilih. Summarize tidak membatalkan apa pun; fitur ini hanya meringkas—pesan asli tetap ada di transkrip sesi sebagai referensi, tetapi hanya ringkasannya yang tersisa di konteks aktif. Gunakan restore jika Anda ingin keadaan menjadi “seolah-olah ini tidak pernah terjadi.” Gunakan summarize jika Anda ingin “menyimpannya, tetapi tidak memakan ruang konteks.” Setelah `Restore conversation` atau `Summarize from here`, teks asli prompt yang dipilih akan kembali ke kolom input—Anda dapat mengedit dan mengirimkannya lagi. Setelah `Summarize up to here`, kolom input kosong, dan Anda tetap berada di akhir percakapan. ## Perubahan apa yang TIDAK dibatalkan oleh /rewind?
Poin utama `/rewind` hanya melacak perubahan yang dibuat Claude melalui alat pengeditan filenya sendiri. Fitur ini tidak dapat melihat atau memulihkan hal lain. Ada tiga kelas perubahan yang tidak terlihat: perintah bash (rm, mv, cp), pengeditan eksternal (edit manual Anda di IDE, perubahan dari sesi lain), dan operasi di luar file (migrasi basis data, git push, panggilan API jarak jauh).
Inilah keterbatasan utama yang dihadapi orang: `/rewind` menampilkan tanda centang hijau dan menyatakan “rewind berhasil”, tetapi proyek masih rusak karena Claude melakukan lebih dari sekadar mengubah file. Mari kita lihat tiga kasusnya. **1. Perintah Bash tidak dilacak.** Jika Claude menjalankan `rm file.txt` atau `mv old.txt new.txt` dalam satu giliran, perubahan tersebut tidak akan disertakan dalam checkpoint. Dokumentasi Anthropic menyatakannya secara eksplisit:

Checkpointing tidak melacak file yang diubah melalui perintah bash. Misalnya, jika Claude Code menjalankan rm file.txt, mv old.txt new.txt, cp source.txt dest.txt, perubahan file tersebut tidak dapat dibatalkan melalui rewind.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Artinya, jika Claude menghapus, memindahkan, atau menyalin file sendiri menggunakan alat bash, `/rewind` tidak akan memulihkan semuanya. `git checkout` atau pemulihan dari cadangan dapat membantu, tetapi langkahnya lebih banyak daripada sekadar menekan dua tombol. **2. Pengeditan eksternal tidak terdeteksi.** Jika Anda membuka file secara manual di VS Code dan mengedit sesuatu, atau sesi Claude kedua mengubah file yang sama secara paralel, sesi pertama tidak dapat melihat perubahan tersebut. Snapshot checkpoint diambil saat Claude menyelesaikan satu giliran dalam sesi saat ini. Apa pun yang terjadi di antara giliran berada di luar tanggung jawabnya. **3. Operasi di luar file sama sekali tidak tercakup.** Migrasi Prisma yang diterapkan melalui `npx prisma migrate dev` mengubah skema basis data—`/rewind` tidak akan membatalkannya karena basis data berada di luar sistem file proyek. Force-push ke `origin/main` sama saja: commit dikirim ke server jarak jauh, dan checkpoint tidak akan mengembalikannya. Panggilan API jarak jauh yang menagih uang atau menghapus catatan hanya dapat dibatalkan melalui mekanisme API itu sendiri. **Aturan:** Jika tugas memengaruhi sesuatu di luar file proyek—migrasi basis data, git push, API jarak jauh—siapkan strategi rollback terpisah untuk setiap dampak eksternal. `/rewind` hanyalah riwayat file lokal dalam sesi saat ini. ## /rewind vs git: apa bedanya, dan mengapa Anda memerlukan keduanya?
Poin utama `/rewind` adalah rollback lokal dalam satu sesi Claude Code. Fitur ini menyimpan snapshot inkremental hingga 30 hari, maksimal 100 per sesi. git adalah riwayat proyek jangka panjang yang dibagikan dengan tim, lengkap dengan cabang, konflik penggabungan, dan repositori jarak jauh. Yang satu tidak menggantikan yang lain. Praktik terbaiknya adalah membuat `git commit` di setiap tonggak logis dan mengandalkan `/rewind` di antara commit.
Dokumentasi Anthropic menyatakan pasangan ini secara langsung:

Checkpoint dirancang untuk pemulihan cepat di tingkat sesi. Untuk commit, cabang, dan riwayat jangka panjang, terus gunakan sistem kontrol versi (misalnya, Git). Checkpoint melengkapi, tetapi tidak menggantikan, kontrol versi biasa. Anggap checkpoint sebagai 'pembatalan lokal' dan Git sebagai 'riwayat permanen'.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Perbedaannya dalam satu tabel: | Parameter | /rewind | git | |----|----|----| | Granularitas | Setiap giliran dalam percakapan | Setiap commit | | Penyimpanan | Hingga 30 hari, maksimal 100 per sesi, lokal di `~/.claude/file-history/` | Permanen, di `.git/` repositori dan di server jarak jauh | | Yang dilacak | Pengeditan Claude melalui alatnya sendiri | Semua perubahan yang di-commit | | Yang TIDAK dilacak | Bash, pengeditan eksternal, migrasi, push | Perubahan yang belum di-commit | | Perintah | Perintah di dalam Claude | Sistem kontrol versi eksternal | | Memundurkan percakapan | Ya | Tidak | | Berfungsi lintas sesi | Hanya dalam sesi yang sama | Di mana saja | Pasangannya sederhana: setiap kali Anda mencapai keadaan “ini berfungsi, dan saya tidak ingin kehilangannya,” buat `git commit`. Di antara commit, andalkan `/rewind`—fitur ini instan, tidak memerlukan pesan commit, dan tidak memenuhi riwayat git dengan keadaan perantara. Setelah pekerjaan selesai, buat commit—sebaiknya commit yang bermakna dan atomik. ## Mengapa satu /rewind tidak mencakup seluruh tugas? Pembatalan adalah salah satu kasus **rekayasa konteks**. Kelola konteks sesi (kapan harus membuat commit, kapan menekan `/rewind`, aturan apa yang perlu dimasukkan ke `CLAUDE.md`) dan Anda akan mendapatkan Claude yang dapat diprediksi, tidak merusak proyek atau menghilangkan pekerjaan. ## Mengapa `git reset --hard` berbahaya saat Anda meminta Claude untuk “kembali”?
Poin utama Dalam bahasa alami, “kembali” berarti “lihat riwayat”, bukan “hancurkan”; Claude seharusnya menawarkan `git checkout` sebagai pilihan bawaan, bukan `reset --hard`; perlindungan diatur dalam CLAUDE.md.
Permintaan untuk “menyimpan keadaan saat ini dan kembali ke push terakhir” dapat memicu perintah berikut: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Perintah pertama benar—perubahan yang belum di-commit disimpan dalam stash. Perintah kedua destruktif: perintah itu menulis ulang cabang ke commit `35eb731`, dan semua commit di antara commit tersebut dan `882e618` menjadi yatim. Secara default, commit yatim tetap berada di `.git/objects/` sampai `git gc` dijalankan, yang biasanya terjadi secara otomatis dalam dua minggu. Namun, jika saat itu Anda tidak tahu apa yang harus dilakukan, waktu sudah mulai berpihak pada hilangnya data. Logikanya sederhana: dalam bahasa alami, “kembali,” “mundur,” “pulihkan,” “kembalikan,” dan “batalkan” berarti “lihat kembali” atau “kembali ke tempat yang aman.” Kata-kata itu tidak berarti “hancurkan riwayat.” Perintah `git reset --hard` menghancurkannya—perintah ini menulis ulang cabang dan menghapus commit dari jalur yang dapat dijangkau melalui HEAD. Alternatif yang aman adalah `git checkout `, yang membuat HEAD terlepas dan memungkinkan Anda melihat keadaan lama tanpa menyentuh cabang. Inti praktisnya adalah membuat `git commit` untuk keadaan saat ini sebelum tugas besar apa pun, terutama sebelum melakukan refaktor pada banyak file. Satu commit mengubah kesalahan Claude apa pun menjadi satu perintah `git checkout .` tanpa kehilangan pekerjaan. ## Bagaimana git reflog menyelamatkan Anda setelah reset destruktif?
Poin utama `git reflog` menampilkan riwayat lokal semua perpindahan HEAD dalam repositori—termasuk commit yang dihapus melalui `git reset --hard` atau force-push. Setiap perpindahan disimpan selama 90 hari secara default. Jika Claude (atau Anda, atau orang lain) menghancurkan commit dengan perintah destruktif, `git reflog` akan menampilkan hash-nya, dan Anda dapat memulihkan cabang dengan `git reset --hard `.
Setelah reset destruktif, segera jalankan `git reflog`: ```bash git reflog ``` Keluaran akan terlihat seperti ini: ``` 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}` adalah commit yang “dihancurkan” itu. Commit tersebut belum hilang dari penyimpanan objek lokal git; hanya saja tidak lagi dapat diakses melalui cabang. Untuk memulihkannya: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Setelah itu, cabang kembali memuat seluruh riwayat hingga bencana tersebut. **Keterbatasan Reflog:** 1. **Lokal saja.** Reflog disimpan di `.git/logs/HEAD`; reflog tidak ada di repositori jarak jauh. Jika Anda melakukan force-push lalu menghapus salinan repositori lokal, reflog ikut hilang bersama foldernya. 2. **90 hari secara default.** Entri yang lebih lama mungkin dihapus oleh git gc. Anda dapat mengonfigurasinya dengan `git config gc.reflogExpire 200.days.ago`. 3. **Tidak mencakup hal yang tidak pernah ada di HEAD.** Jika commit hanya ada di stash dan stash tersebut dihancurkan, reflog hanya akan menampilkan keadaan terakhir stash, bukan riwayat internalnya. **Aturan untuk tim:** jangan pernah menjalankan `git gc --aggressive` tepat setelah terjadi bencana. Selidiki dahulu dengan reflog dan pulihkan; lakukan yang lain setelah itu. Jangan pernah menghapus klona repositori lokal sampai Anda yakin semua yang diperlukan sudah di-push. ## Bagaimana melindungi proyek dari perintah git destruktif melalui CLAUDE.md?
Poin utama Di `CLAUDE.md` proyek Anda, tambahkan blok instruksi yang menentukan perintah git mana yang boleh dijalankan Claude sendiri, mana yang memerlukan konfirmasi eksplisit, dan mana yang dilarang tanpa frasa persis dari pengguna. Claude memperlakukan CLAUDE.md sebagai prompt sistem proyek dan secara default mengikuti aturan tersebut. Dengan begitu, satu prompt “berbahaya” berubah menjadi dua perintah aman.
Kerentanannya adalah bahwa secara default Claude tidak memiliki konteks perlindungan. Claude menafsirkan “kembali” sebagai `git reset --hard` karena secara teknis itu metode yang valid. Tambahkan perlindungan ke `CLAUDE.md`—file prompt sistem proyek. **Aturan minimal** (masukkan ke `CLAUDE.md` Anda): ```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. ``` **Aturan lanjutan** untuk tim (tambahkan ke `CLAUDE.md` di akar repositori): ```markdown ## Git Workflow Rules - Buat commit pada setiap pencapaian yang berfungsi. Sebelum commit WIP, jalankan `git status` dan `git diff`, stage hanya file bernama yang secara eksplisit ditinjau dengan `git add -- path/to/file`, lalu periksa diff yang di-stage sebelum commit. Timer adalah pengingat untuk meninjau, bukan izin untuk men-stage seluruh working tree. - 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. ``` Setelah blok-blok ini ditambahkan, frasa “kembali ke push terakhir” berikutnya akan menghasilkan respons seperti ini: > Saya melihat 3 file yang belum di-commit dan 4 commit lebih baru daripada push terakhir. Ada dua opsi: > > 1. AMAN: buat cabang `view-last-push` melalui `git checkout `—saya akan mempertahankan semua pekerjaan, tetapi sementara menampilkan keadaan push tersebut. > 2. DESTRUKTIF: `git reset --hard `—saya akan menghancurkan 4 commit dan perubahan yang belum di-commit secara permanen. Perubahan itu hanya dapat dipulihkan melalui `git reflog` dalam 90 hari. Mana yang Anda pilih? Itu hanya perlu setengah menit berbincang, bukan empat jam kehilangan pekerjaan. ## Apa saja 5 cara untuk membatalkan di Claude Code, dan bagaimana memilih yang tepat?
Poin utama Jika terjadi kesalahan, ada lima level langkah pemulihan: `/rewind` (dalam satu sesi), `git checkout .` (perubahan yang belum di-commit), `git checkout ` (kembali ke commit lama tanpa kehilangan riwayat), `git reset --hard ` (memundurkan cabang dan kehilangan commit yang lebih baru), `git reflog` + pemulihan (bencana, semuanya hilang). Setiap level lebih berat dan berbahaya daripada sebelumnya.
Skenario “Claude merusaknya, saya perlu segera memulihkan” dijalankan dari bawah ke atas mengikuti tangga ini. Selalu mulai dari level 1. **Level 1. `/rewind`—pembatalan instan dalam satu sesi.** Tekan `Esc Esc` atau ketik `/rewind`. Pilih titik sebelum kerusakan. Pilih mode (biasanya `Restore code and conversation`). Sedetik kemudian, Anda kembali ke masa lalu dan dapat memulai lagi. Mencakup 80% kasus “Claude melakukan hal yang salah”. **Level 2. `git checkout .`—membatalkan semua perubahan yang belum di-commit.** ```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 ``` Berguna ketika `/rewind` tidak berhasil (misalnya, Claude menyentuh file melalui bash) atau ketika Anda perlu membatalkan perubahan di luar riwayat sesi. Semua perubahan yang belum di-commit akan hilang secara permanen. Jika Anda mungkin menyesalinya, jalankan `git stash` terlebih dahulu (lihat level 2.5). **Level 2.5. `git stash`—menyimpan perubahan untuk sementara.** ```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 ``` Kompromi yang baik antara “hilang selamanya” dan “biarkan seperti adanya.” Stash tetap tersimpan secara lokal sampai dihapus secara eksplisit. **Level 3. `git checkout `—kembali ke commit lama tanpa kehilangan riwayat.** ```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 ``` Ini adalah “kembali sementara” yang aman. Detached HEAD tidak mengubah cabang; pekerjaan Anda saat ini di `main` (atau cabang mana pun yang digunakan) tetap utuh. Jika ingin bekerja dengan keadaan ini, buat cabang. **Level 4. `git reset --hard `—memundurkan cabang ke suatu titik.** ⚠️ Destruktif. Commit yang lebih baru daripada hash yang ditentukan akan menjadi yatim. ```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 ``` Gunakan hanya jika Anda yakin tidak memerlukan commit yang lebih baru. Dan selalu periksa `git reflog` SEBELUM reset agar tahu ke mana harus kembali jika berubah pikiran. **Level 5. `git reflog` + pemulihan—skenario bencana.** Seseorang (Claude, Anda, rekan kerja) sudah menjalankan `git reset --hard` atau force-push dan menghapus pekerjaan. Apa yang harus dilakukan? ```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 ``` Jika reflog sudah dihapus (secara default setelah 90 hari), upaya terakhir adalah `git fsck --lost-found`, yang akan menampilkan commit yang tidak tertaut di `.git/objects/`. Ini hampir seperti arkeologi, tetapi kadang berhasil. **Aturan untuk memilih level:** | Yang terjadi | Level | |-----------------------------------------------|-----------------------------| | Claude menulis ulang 3 file dengan cara yang salah | 1\. `/rewind` | | Saya sudah mencoba, tidak menyukainya, sesi tidak membantu | 2\. `git checkout .` | | Saya merusaknya secara manual, enggan kehilangan perubahan dan mungkin ingin memulihkannya | 2.5. `git stash` | | Saya sudah membuat commit; perlu kembali satu commit | 3\. `git checkout ` | | Saya yakin tidak memerlukan commit yang lebih baru | 4\. `git reset --hard` | | Sudah terhapus oleh perintah destruktif | 5\. `git reflog` | ## Bagaimana melindungi proyek agar tidak ada yang perlu dibatalkan?
Poin utama Pembatalan terbaik adalah yang tidak diperlukan. Tiga aturan perlindungan: tinjau kemajuan setiap 30 menit dan commit pencapaian yang berfungsi dengan men-stage secara eksplisit hanya jalur yang telah ditinjau; masukkan baris `.claude/personal/` dan `.env*` yang wajib ke `.gitignore`; lakukan eksperimen besar di cabang terpisah dengan `git checkout -b experiment-`. Ini mempersempit celah pemulihan untuk file yang sudah di-commit; sistem eksternal dan pekerjaan yang belum di-commit tetap memerlukan rencana pemulihannya sendiri.
**Aturan 1. Buat commit setiap 30 menit.** Jangan tunggu sampai “tugas selesai.” Buat commit untuk setiap langkah perantara yang berhasil. Pesan commit bisa apa saja; yang penting, Claude (atau Anda) dapat kembali ke keadaan yang berfungsi dengan satu perintah `git checkout`. ```bash # at the beginning of a task git status # periksa semua jalur yang sudah dan belum di-stage git diff # tinjau perubahan # Ganti jalur contoh dengan file sebenarnya yang telah ditinjau. git add -- path/to/file.ts git diff --cached # verifikasi persis yang akan di-commit 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 # jalur sebenarnya yang ditinjau, bukan wildcard direktori 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" ``` Jika menambahkan pengingat PostToolUse, pertahankan aturan tinjauan dan staging jalur eksplisit yang sama. Jangan jadikan timer sebagai commit otomatis tanpa pemeriksaan: edit tidak terkait atau file yang sudah di-stage bisa masuk commit. **Aturan 2. `.gitignore` minimum.** Baris berikut wajib ada di akar proyek: ```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/ ``` Saya menyimpan folder `.claude/personal/` untuk eksperimen dan catatan pribadi yang tidak boleh disertakan dalam repositori bersama. Folder `.claude/sessions/` dan `.claude/file-history/` adalah penyimpanan lokal Claude Code; folder tersebut tidak termasuk dalam repositori, memakan banyak ruang, dan terikat pada mesin tertentu. **Aturan 3. Eksperimen di cabang terpisah.** Jika tugasnya besar (refaktor 10+ file, migrasi ke basis data baru, penulisan ulang modul), jangan kerjakan di cabang utama: ```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 ``` Kebiasaan sederhana ini mengubah “Claude menghancurkan proyek” menjadi “Claude merusak satu cabang, saya menghapusnya, lalu kita mulai lagi.” **Aturan 4. Sebelum operasi berbahaya, gunakan `git tag`.** Sebelum migrasi basis data, refaktor besar, atau pembaruan dependensi, buat tag: ```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 ``` Tag adalah penunjuk bernama ke commit yang tidak akan hilang meskipun reflog dibersihkan. ## Berikutnya: bagaimana pembatalan cocok dengan rekayasa konteks?
Poin utama Pembatalan bukan keterampilan terpisah, melainkan bagian dari pengelolaan konteks sesi Claude Code. Saat Anda tahu kapan harus menekan `/rewind`, kapan membuat `git commit`, dan kapan menggunakan `git stash`, Anda mengelola alur kerja secara keseluruhan, bukan sekadar satu perintah. Hal ini termasuk bagian dari **Context Engineering**. Tanpanya, Claude bertindak seperti asisten biasa; dengannya, Claude menjadi alat yang dapat diprediksi.
Ketiga level pembatalan ini adalah infrastruktur bagi satu keterampilan: mengetahui cara memulihkan keadaan saat terjadi kerusakan. Keterampilan itu sendiri cakupannya sempit. Namun, jika digabungkan dengan alat rekayasa konteks lainnya, hasilnya menjadi sesuatu yang lebih besar. Plan Mode tidak langsung mengizinkan Anda menulis kode—pertama ada rencana, lalu konfirmasi, kemudian pelaksanaan. Ini adalah pembatalan preventif: Anda tidak menulis sesuatu yang nantinya harus dibatalkan karena rencananya sudah ditinjau terlebih dahulu. Baca lebih lanjut di panduan [Plan Mode di Claude Code](https://ailoot.ai/blog/id/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/id/claude-md-template/) menetapkan aturan yang secara default dipatuhi Claude, termasuk Git Safety Protocol yang dibahas di atas. Ini adalah perlindungan preventif terhadap perintah destruktif. [Second Brain](https://ailoot.ai/blog/id/claude-code-second-brain/) memberi Claude memori tentang proyek di antara sesi—Claude mengetahui kode yang Anda miliki, logika bisnisnya, dan kesepakatan yang dibuat sebelumnya. Semakin banyak memori, semakin kecil kemungkinan Claude melakukan hal yang salah. [Skills dan subagent](https://ailoot.ai/blog/id/claude-code-skills-library/) adalah metodologi Anda dalam kode. Jika alur kerja git yang benar ditanamkan ke dalam Skill, tidak ada subagent yang akan menjalankan `git reset --hard` tanpa konfirmasi. Dan semua ini bersama-sama adalah **Context Engineering**. Kelola konteks sebelum prompt, bukan saat menjalankannya. Baca lebih lanjut di [apa itu context engineering](https://ailoot.ai/blog/id/context-engineering/). Pembatalan adalah garis pertahanan terakhir. Plan Mode + CLAUDE.md + Second Brain + Skills adalah empat lapis pertama. Jika sudah disiapkan, pembatalan menjadi jarang dan cepat. Jika tidak, pembatalan menjadi rutinitas harian.
### Sumber - [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)
Pembatalan dimulai saat perencanaan berakhir. [Open Ailoot](https://ailoot.ai/). ## Pertanyaan tentang Cara membatalkan perubahan di Claude Code: /rewind dan git ### Haruskah checkpoint WIP memakai git add .? Tidak. Jalankan `git status` dan `git diff`, stage hanya file bernama yang telah ditinjau, lalu periksa `git diff --cached` sebelum commit. Checkpoint berkala tidak mengizinkan penyertaan perubahan tidak terkait atau yang sebelumnya sudah di-stage. ### Bisakah /rewind membatalkan migrasi basis data atau tindakan API jarak jauh? Tidak. Panduan membatasi checkpoint pada edit file yang didukung dalam sesi. Dampak pada basis data, Git jarak jauh, dan API memerlukan langkah pemulihan terpisah; gunakan Git atau cadangan untuk file di luar cakupan checkpoint. ## Ailoot · Perusahaan dan portofolio proyeknya Ailoot bertumpu pada pengalaman operasional yang teruji, basis pelanggan yang besar, layanan yang stabil, dan pemantauan KPI berkelanjutan. Perusahaan dan portofolio proyeknya: jutaan pelanggan; penjualan miliaran setiap bulan. Ailoot memanfaatkan pengalaman operasional ini untuk akses API ke fitur AI dalam produk pelanggan, agen, aplikasi, dan otomatisasi.