# Claude Code’da o‘zgarishlarni qanday bekor qilish mumkin: /rewind va git > Orqaga qaytarish rejimlari, checkpoint cheklovlari, git checkout, stash, reflog va halokatli buyruqlardan himoyalanish. Holatni tiklashning besh usuli. Source: https://ailoot.ai/blog/uz/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/uz/claude-code-undo-changes/ Language: uz Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-d87c7aa41a6d9d891be03014c6a15df208fdd98f89d8af35c1c01fb07e74dbe6 [Ailoot bilan ishlash bo‘yicha amaliy ma’lumotlar hujjatlarda mavjud](https://ailoot.ai/docs/). ## Claude Code’da bekor qilish nima va nega uchta daraja yetarli emas?
Asosiy xulosalar Claude Code’da bekor qilishning uchta darajasi bor: ichki `/rewind` buyrug‘i (joriy seans ichida darhol tiklash), `git checkout` (oxirgi commitga qaytish) va `git reflog` (`git reset --hard` bajarilgan bo‘lsa, halokatli vaziyat uchun xavfsizlik chorasi). Har bir daraja o‘ziga xos xatolar sinfini qamrab oladi va o‘z chegarasidan tashqariga chiqmaydi. Faqat `/rewind`ni bilish jiddiy xatoga yo‘l qo‘yilganida sizni himoyasiz qoldiradi.
Claude Code’dan foydalanishni boshlaganimning birinchi haftasida `/rewind`ni yoqdim: u ikki so‘rovda loyihamning autentifikatsiya mantiqini buzib qo‘ydi. Orqaga qaytardim, yengil nafas oldim va ishni davom ettirdim. Bir oy o‘tgach, yana bir vaziyat yuz berdi: sxema migratsiyasini yozayotgan edim, Claude yordam berdi, commit qildim, tarmoqlarni almashtirdim — shunda zarur bir qadamni unutganimni angladim. `/rewind` yordam bermadi — seans allaqachon boshqacha edi. Oldingi commitga `git checkout` qilish yordam berdi. Yana bir oy o‘tgach, agentga tasodifan “hammasini oxirgi push holatiga qaytar” dedim, u esa `git reset --hard` bajarib, uch soatlik ishimni barbod qildi. `git reflog` meni qutqardi — yo‘q qilingan commitlarning xeshlari hali ham bor edi. Bu uch voqea turlicha ishlaydigan, turli xatolarni tutib qoladigan va barchasi kerak bo‘ladigan uchta himoya darajasini ko‘rsatadi. Ushbu qo‘llanmada har bir daraja buyruqlari, cheklovlari va misollari bilan tushuntiriladi. Shuningdek, Claude loyihani birinchi urinishdayoq ishdan chiqarmasligi uchun uni oldindan qanday sozlash ko‘rsatiladi. **Bekor qilishning 3 darajasi — nima va qachon:** | Daraja | Buyruq | Qamrab oladi | Qamrab OLMAYDI | |----|----|----|----| | 1\. Seans ichida | `/rewind` yoki `Esc Esc` | Claude o‘z vositalari orqali o‘zgartirgan fayllar; suhbat tarixi | Bash buyruqlari, tashqi tahrirlagichlar, ma’lumotlar bazasi migratsiyalari | | 2\. Commitdan oldin | `git checkout .` yoki `git stash` | Fayllardagi barcha commit qilinmagan o‘zgarishlar | Commit qilingan commitlar | | 3\. Falokat | `git reflog` + `git reset --hard ` | `reset --hard` yoki force-push bilan yo‘q qilingan commitlar | Buzuvchi bash buyruqlari (rm, ma’lumotlar bazasi migratsiyalari) | Keyin har bir darajani ko‘rib chiqamiz: aynan nima qilish, qanday xatolardan ehtiyot bo‘lish va hech narsa buzilmagani uchun bekor qilishga hojat qolmaydigan qilib sozlash. ## /rewind’ni qanday chaqirasiz: buyruq bilanmi yoki Esc-Esc bilanmi?
Asosiy xulosalar Claude Code’da Rewind menyusini ochishning ikki yo‘li bor. Birinchisi — kiritish maydoniga `/rewind` yozish. Ikkinchisi — kiritish maydoni bo‘sh bo‘lganda `Esc` tugmasini ikki marta bosish. Maydonda matn bo‘lsa, Esc’ni ikki marta bosish avval uni tozalab, mazmunini kiritish tarixiga saqlaydi; menyuni ochish uchun yana ikki marta bosish kerak. `/rewind` buyrug‘ining taxallusi `/checkpoint`.
Har bir javobdan keyin Claude shu seansda tahrirlagan barcha fayllarning suratini avtomatik oladi. Suratlar `~/.claude/file-history/{sessionId}/` ichida saqlanib, 30 kungacha turadi. Suratlar bosqichma-bosqich olinadi — butun fayl emas, faqat holatlar orasidagi farqlar saqlanadi. Odatiy holatda har bir seans uchun 100 tagacha surat saqlanadi. Demak, aksariyat real loyihalarda kun davomida Claude kiritgan barcha o‘zgarishlarning to‘liq tarixi istalgan paytda mavjud bo‘ladi. Orqaga qaytarish menyusini ochish uchun kiritish maydoni bo‘sh bo‘lganda `Esc`ni ikki marta bosing: ``` [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) ... ``` Kiritish maydonida matn bo‘lsa, `Esc`ni ikki marta bosishning birinchi harakati uni tozalab, `Up` tarixiga saqlaydi. Bu yozishni boshlab qo‘yganingizda, lekin orqaga qaytish kerakligini anglaganingizda foydali. Anthropic’ning rasmiy hujjatlaridan iqtibos:

So‘rov maydonida matn bo‘lsa, Esc’ni ikki marta bosish menyuni ochish o‘rniga avval matnni tozalaydi. Tozalangan matn kiritish tarixida saqlanadi, shuning uchun orqaga qaytarish menyusidan keyin yuqoriga strelka tugmasi bilan uni tiklashingiz mumkin.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
`/rewind` buyrug‘i ham xuddi shu ishni qiladi — menyuni ochadi. `/checkpoint` taxallusi ham ayni joyga olib boradi. Qaysi usul qulayroq ekani odatga bog‘liq. Men `Esc Esc`dan foydalanaman — bu tezroq va qo‘llarimni klaviaturadan olishimga hojat yo‘q. ## Rewind menyusidagi 6 rejim: qaysi birini va qachon tanlash kerak?
Asosiy xulosalar Rewind menyusida nuqtani tanlaganingizdan so‘ng, olti rejimli ikkinchi menyu paydo bo‘ladi. Uchtasi holatni tiklaydi (`Restore code and conversation`, `Restore conversation`, `Restore code`), ikkitasi tarixni ixchamlaydi (`Summarize from here`, `Summarize up to here`), bittasi amalni bekor qiladi (`Never mind`). Eng ko‘p uchraydigan holat — “kodni ham, suhbatni ham orqaga qaytarish” — birinchi variant.
Ro‘yxatdan nuqtani tanlang, shunda amallar menyusiga o‘tasiz. Unda oltita band bor, har biri boshqa ishni bajaradi. **Rejimlarning to‘liq jadvali:** | Rejim | Nima qiladi | Qachon tanlash kerak | |----|----|----| | `Restore code and conversation` | Fayllar va suhbat tarixini tanlangan nuqtaga qaytaradi | Eng ko‘p uchraydigan holat: Claude noto‘g‘ri yo‘nalishga ketdi, men esa to‘g‘ri ifoda bilan boshidan boshlamoqchiman | | `Restore conversation` | Faqat suhbat tarixini orqaga qaytaradi; fayllar hozirgi holicha qoladi | Kod yaxshi, lekin suhbat izdan chiqdi; joriy o‘zgarishlarni saqlagan holda shu nuqtadan fikrimni boshqacha ifodalayman | | `Restore code` | Fayllarni orqaga qaytaradi; suhbat o‘z holicha qoladi | Claude o‘zgarishlarining ayrimlari keraksiz bo‘ldi, lekin suhbat konteksti (masalan, keyingi qadamlarni kelishib olganimiz) menga hali ham kerak | | `Summarize from here` | Tanlangan nuqtadan KEYINGI barcha narsani xulosaga siqadi. Fayllarga tegmaydi | Uzoq nosozlikni tuzatish seansida kontekst tugadi; dastlabki ko‘rsatmalarni to‘liq saqlab, joy bo‘shatishim kerak | | `Summarize up to here` | Tanlangan nuqtadan OLDINGI barcha narsani xulosaga siqadi. Fayllarga tegmaydi | Avval uzoq brifing, keyin aniq vazifa bo‘ldi — brifingni bitta xabarga siqib, so‘nggi ishni o‘z holicha qoldiramiz | | `Never mind` | Menyuni o‘zgarishsiz yopadi | Fikrimdan qaytdim | `Summarize up to here` funksiyasi Claude Code v2.1.139-v2.1.142 versiyalarida, 2026-yil 11–15-may kunlari, 20-haftada chiqarilgan:

Rewind menyusidagi “Summarize up to here” yordamida dastlabki kontekstni ixchamlashingiz mumkin.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
`Restore` va `Summarize` o‘rtasidagi farq juda muhim. Restore oldingi holatga qaytarib, tanlangan nuqtadan keyin sodir bo‘lgan hamma narsani bekor qiladi. Summarize hech narsani bekor qilmaydi; faqat ixchamlaydi — asl xabarlar sessiya stenogrammasida qoladi, lekin faol kontekstda faqat xulosa qoladi. “Go‘yo bu hech qachon bo‘lmagandek” qilish uchun restore’dan foydalaning. “Saqlab qolish, lekin kontekst joyini band qilmaslik” uchun summarize’dan foydalaning. `Restore conversation` yoki `Summarize from here`dan keyin tanlangan so‘rovning asl matni kiritish maydoniga qaytadi — uni tahrirlab, qayta yuborishingiz mumkin. `Summarize up to here`dan keyin kiritish maydoni bo‘sh qoladi va suhbat oxirida qolasiz. ## /rewind qaysi o‘zgarishlarni bekor QILMAYDI?
Asosiy xulosalar `/rewind` faqat Claude’ning o‘z fayl tahrirlash vositalari orqali kiritgan o‘zgarishlarini kuzatadi. Boshqa narsalarni ko‘ra olmaydi yoki tiklay olmaydi. Ko‘rinmaydigan o‘zgarishlarning uchta turi bor: bash buyruqlari (rm, mv, cp), tashqi tahrirlar (IDE’dagi qo‘lda tahrirlaringiz, boshqa seanslardagi o‘zgarishlar) va fayllardan tashqaridagi amallar (ma’lumotlar bazasi migratsiyalari, git push, masofaviy API chaqiruvlari).
Odamlar duch keladigan asosiy cheklov shu: `/rewind` yashil belgi ko‘rsatib, “orqaga qaytarish muvaffaqiyatli” deydi, ammo Claude fayllardan ko‘prog‘iga tegib ketgani uchun loyiha hanuz buzilgan bo‘ladi. Uch holatni ko‘rib chiqaylik. **1. Bash buyruqlari kuzatilmaydi.** Agar Claude biror yurishda `rm file.txt` yoki `mv old.txt new.txt` bajarsa, bu o‘zgarishlar checkpoint’ga kirmaydi. Anthropic hujjatlarida aniq aytilgan:

Checkpoint tizimi bash buyruqlari orqali o‘zgartirilgan fayllarni kuzatmaydi. Masalan, Claude Code `rm file.txt`, `mv old.txt new.txt`, `cp source.txt dest.txt` bajarsa, fayllardagi bu o‘zgarishlarni orqaga qaytarish orqali bekor qilib bo‘lmaydi.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Demak, Claude bash vositasidan foydalanib faylni o‘zi o‘chirsa, ko‘chirsa yoki nusxalasa, `/rewind` hamma narsani tiklay olmaydi. `git checkout` yoki zaxira nusxadan tiklash yordam berishi mumkin, ammo buning uchun ikki tugmani bosishdan ko‘prog‘i kerak bo‘ladi. **2. Tashqi tahrirlar aniqlanmaydi.** Faylni VS Code’da qo‘lda ochib tahrirlasangiz yoki ikkinchi Claude seansi ayni fayllarni parallel o‘zgartirsa, birinchi seans bu o‘zgarishlarni ko‘ra olmaydi. Joriy seansda Claude navbatini tugatganida checkpoint surati olinadi. Navbatlar orasida sodir bo‘ladigan ishlar uning mas’uliyatidan tashqarida. **3. Fayllardan tashqaridagi amallar umuman qamrab olinmaydi.** `npx prisma migrate dev` orqali qo‘llangan Prisma migratsiyasi ma’lumotlar bazasi sxemasini o‘zgartiradi — `/rewind` buni bekor qilmaydi, chunki ma’lumotlar bazasi loyiha fayl tizimidan tashqarida. `origin/main`ga force-push ham shunday: commit masofaviy serverga yuborilgan va checkpoint uni qaytarib olib kelmaydi. Pul yechgan yoki yozuvni o‘chirgan masofaviy API chaqiruvini faqat o‘sha API’ning o‘z vositalari bilan bekor qilish mumkin. **Qoida:** Vazifa loyiha fayllaridan tashqaridagi narsalarga — ma’lumotlar bazasi migratsiyalari, git push, masofaviy API’lar — ta’sir qilsa, har bir tashqi ta’sir uchun alohida qaytarish strategiyasini tayyorlang. `/rewind` faqat joriy seansdagi mahalliy fayllar tarixini qamrab oladi. ## /rewind va git: ular nimasi bilan farq qiladi va nega ikkalasi ham kerak?
Asosiy xulosalar `/rewind` — bitta Claude Code seansi ichidagi mahalliy qaytarish vositasi. U 30 kungacha, har bir seansga 100 tagacha bosqichma-bosqich surat saqlaydi. git esa tarmoqlar, birlashtirish ziddiyatlari va masofaviy omborga ega, jamoa bilan bo‘lishiladigan uzoq muddatli loyiha tarixidir. Biri ikkinchisining o‘rnini bosmaydi. Eng yaxshi amaliyot — har bir mantiqiy bosqichda `git commit` qilish va commitlar orasida `/rewind`ga tayanish.
Anthropic hujjatlarida bu juftlik bevosita bayon qilingan:

Checkpointlar seans darajasida tez tiklash uchun mo‘ljallangan. Commitlar, tarmoqlar va uzoq muddatli tarix uchun versiyalarni boshqarish tizimidan (masalan, Git) foydalanishda davom eting. Checkpointlar odatiy versiya boshqaruvini to‘ldiradi, ammo uning o‘rnini bosmaydi. Checkpointlarni “mahalliy bekor qilish”, Git’ni esa “doimiy tarix” deb tasavvur qiling.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Farqlar bitta jadvalda: | Parametr | /rewind | git | |----|----|----| | Mayda darajasi | Suhbatdagi har bir navbat | Har bir commit | | Saqlash | 30 kungacha, har bir seansga 100 tagacha, mahalliy `~/.claude/file-history/` ichida | Doimiy ravishda, omborning `.git/` papkasida va masofaviy serverda | | Kuzatadigan narsasi | Claude’ning o‘z vositalari orqali kiritgan tahrirlari | Barcha commit qilingan o‘zgarishlar | | Kuzatmaydigan narsasi | Bash, tashqi tahrirlar, migratsiyalar, push | Commit qilinmagan o‘zgarishlar | | Buyruq | Claude ichidagi buyruq | Tashqi versiyalarni boshqarish tizimi | | Suhbatni orqaga qaytaradi | Ha | Yo‘q | | Seanslararo ishlaydi | Faqat ayni seans ichida | Hamma joyda | Ularning birgalikda ishlash qoidasi oddiy: “bu ishlayapti va buni yo‘qotishni xohlamayman” degan holatga yetganingizda, `git commit` qiling. Commitlar orasida `/rewind`ga tayaning — u darhol ishlaydi, commit xabarini talab qilmaydi va git tarixini oraliq holatlar bilan to‘ldirmaydi. Ish tugaganda commit qiling — yaxshisi, mazmunli va yaxlit commit. ## Nega bitta /rewind butun vazifani qamrab olmaydi? ## Claude’dan “orqaga qaytar” deb so‘raganda `git reset --hard` nega xavfli?
Asosiy xulosalar Oddiy tilda “orqaga qaytar” tarixga qarashni anglatadi, uni yo‘q qilishni emas; Claude odatiy holatda `reset --hard` emas, `git checkout`ni taklif qilishi kerak; himoya CLAUDE.md’da sozlanadi.
“Joriy holatni saqla va oxirgi push holatiga qaytar” degan so‘rov quyidagi buyruqlarga olib kelishi mumkin: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saqlanmagan o‘zgarishlarni saqladi git reset --hard 35eb731 # d63695e..882e618 commitlarini yo‘q qildi ``` Birinchi buyruq to‘g‘ri edi — u commit qilinmagan o‘zgarishlarni stash’da saqladi. Ikkinchisi buzuvchi bo‘ldi: u tarmoqni `35eb731` commitiga qayta yozdi va u bilan `882e618` orasidagi barcha commitlar yetim qoldi. Odatiy holatda yetim commitlar `git gc` ishga tushguncha `.git/objects/` ichida qoladi; bu odatda ikki hafta ichida avtomatik yuz beradi. Ammo o‘sha payt nima qilishni bilmagan bo‘lsangiz, vaqt sizga qarshi ishlay boshlagan edi. Mantiq oddiy: oddiy tildagi “orqaga qaytar”, “oldingi holatga bor”, “tikla”, “qaytar” va “bekor qil” iboralari “ortga qarash” yoki “xavfsiz joyga qaytish”ni anglatadi. Ular “tarixni yo‘q qilish” degani emas. `git reset --hard` buyrug‘i tarixni yo‘q qiladi — tarmoqni qayta yozadi va commitlarni HEAD’dan yetib boriladiganlar qatoridan olib tashlaydi. Xavfsiz muqobil — `git checkout `: u ajratilgan HEAD yaratib, tarmoqlarga tegmasdan eski holatni ko‘rish imkonini beradi. Amaliy asosiy xulosa — har qanday jiddiy vazifadan, ayniqsa bir nechta faylni refaktorlashdan oldin joriy holatni `git commit` qilish. Bitta commit Claude’ning istalgan xatosini ishni yo‘qotmasdan bitta `git checkout .` buyrug‘i bilan bartaraf etish imkonini beradi. ## Halokatli resetdan keyin git reflog qanday qutqaradi?
Asosiy xulosalar `git reflog` ombordagi barcha HEAD siljishlarining mahalliy tarixini ko‘rsatadi — hatto `git reset --hard` yoki force-push orqali olib tashlangan commitlarni ham. Odatiy holatda har bir siljish 90 kun saqlanadi. Agar Claude (yoki siz, yoxud boshqa birov) buzuvchi buyruq bilan commitlarni yo‘q qilgan bo‘lsa, `git reflog` ularning xeshlarini ko‘rsatadi va `git reset --hard ` bilan tarmoqni tiklashingiz mumkin.
Halokatli reset’dan keyin darhol `git reflog` ishlating: ```bash git reflog ``` Natija quyidagicha ko‘rinadi: ``` 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}` dan `HEAD@{3}` gacha bo‘lganlar aynan o‘sha “yo‘q qilingan” commitlardir. Ular git’ning mahalliy obyektlar omboridan yo‘qolmagan; shunchaki tarmoq orqali ularga yetib borib bo‘lmaydigan bo‘lgan. Ularni tiklash uchun: ```bash # Oxirgi “yo‘q qilingan” commitdan tarmoq yarating git branch recovered-work 882e618 # Yoki to‘g‘ridan-to‘g‘ri o‘ting git reset --hard 882e618 ``` Shundan keyin tarmoq falokatgacha bo‘lgan butun tarixni yana o‘z ichiga oladi. **Reflog cheklovlari:** 1. **Faqat mahalliy.** Reflog `.git/logs/HEAD` ichida saqlanadi; masofaviy omborda bo‘lmaydi. Force-push qilib, keyin mahalliy ombor nusxasini o‘chirsangiz, reflog ham papka bilan birga yo‘qoladi. 2. **Odatiy holatda 90 kun.** Eski yozuvlar git gc tomonidan o‘chirib yuborilishi mumkin. Buni `git config gc.reflogExpire 200.days.ago` bilan sozlashingiz mumkin. 3. **HEAD’da hech qachon bo‘lmagan narsani qamramaydi.** Agar commit faqat stash’da bo‘lib, stash yo‘q qilingan bo‘lsa, reflog uning ichki tarixini emas, faqat stash’ning eng so‘nggi holatini ko‘rsatadi. **Jamoa qoidasi:** falokat yuz bergan zahoti `git gc --aggressive` ishlatmang. Avval reflog yordamida vaziyatni tekshirib, ishni tiklang; qolgan hamma ishni keyin qiling. Kerakli barcha narsalar push qilinganiga ishonch hosil qilmaguningizcha mahalliy ombor klonini ham o‘chirmang. ## CLAUDE.md orqali loyihani buzuvchi git buyruqlaridan qanday himoyalaysiz?
Asosiy xulosalar Loyihangizdagi `CLAUDE.md` fayliga Claude mustaqil bajara oladigan, aniq tasdiq talab qiladigan va foydalanuvchining aynan belgilangan iborasisiz taqiqlangan git buyruqlarini ko‘rsatuvchi ko‘rsatmalar blokini qo‘shing. Claude CLAUDE.md’ni loyihaning tizim so‘rovi sifatida qabul qiladi va odatda bu qoidalarga amal qiladi. Shu tariqa bitta “xavfli” so‘rov o‘rniga ikkita xavfsiz buyruq ishlatadi.
Zaiflik shundaki, Claude’da odatiy holatda himoya konteksti yo‘q. U “orqaga qaytar”ni `git reset --hard` deb talqin qiladi, chunki texnik jihatdan bu yaroqli usul. Himoyani loyihaning tizim so‘rovi fayli bo‘lgan `CLAUDE.md` ichiga joylashtiring. **Minimal qoida** (`CLAUDE.md` faylingizga qo‘shing): ```markdown ## Git xavfsizlik protokoli - Men bu amallarni ochiq so‘ramagunimcha, HECH QACHON buzuvchi git buyruqlarini (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) bajarmang. Ruxsatsiz buzuvchi amallar foyda bermaydi va ish yo‘qolishiga olib kelishi mumkin. - “orqaga qaytar”, “oldingi holatga bor”, “tikla”, “qaytar”, “bekor qil” deganimda, buni KO‘RIB CHIQISH buyruqlari sifatida talqin qiling: `git log`, `git diff`, `git checkout ` (ajratilgan HEAD yaratadi) yoki `git stash`dan (o‘zgarishlarni saqlaydi) foydalaning. - Quyidagi holatlarning HAR BIRIDA buyruqni bajarishdan oldin tasdiqni so‘rang: - Tarmoqdagi HEAD holatini boshqa commitga o‘zgartiradi - Commit tarixini o‘zgartiradi - Commit qilinmagan ishni yo‘qotishi mumkin - --hard, --force, --aggressive bayroqlarini o‘z ichiga oladi - Har qanday buzuvchi buyruqdan oldin raqamlangan taqqoslashni ko‘rsating: - XAVFSIZ: vaqtincha ko‘rish uchun `git checkout `dan foydalanish - BUZUVCHI: butunlay yo‘q qilish uchun `git reset --hard`dan foydalanish - Bajarishdan oldin mening aniq tanlovimni kuting. ``` Jamoa uchun **kengaytirilgan qoida** (ombor ildizidagi `CLAUDE.md`ga qo‘shing): ```markdown ## Git ish jarayoni qoidalari - Ishlaydigan bosqichda commit qiling. WIP’dan oldin `git status` va `git diff` ni ko‘ring, faqat ko‘rilgan nomli fayllarni `git add -- path/to/file` bilan stage qiling, so‘ng staged diff’ni tekshiring. Taymer butun daraxtni stage qilish ruxsati emas, ko‘rik eslatmasi. - Claude commitlari uchun hech qachon `git add .` yoki `git add -A` ishlatmang. Faqat `git status` + `git diff`dan keyin fayllarni nomi bilan belgilang. - `main` tarmog‘iga `git push --force` qilishdan oldin to‘xtab, mendan so‘rang. Funksional tarmoqlarda oldingi versiyani yo‘qotishga roziligimga amin bo‘lsangizgina, ehtiyotkorlik bilan force-push qiling. - Birlashtirish ziddiyatlarini hal qilayotganda darhol “ours” yoki “theirs”ni tanlamang — avval ikkala variantni ko‘rsating, keyin men qaror qilaman. - `.gitignore` ichida `.env*`, `.claude/personal/`, `node_modules/`, `dist/` bo‘lishi shart. Bular yo‘q bo‘lsa, qo‘shing. ``` Bu bloklarni qo‘shganingizdan keyin, “oxirgi push holatiga qaytar” degan ibora shunday javobga olib keladi: > Men 3 ta commit qilinmagan fayl va oxirgi pushdan oldinda turgan 4 ta commitni ko‘ryapman. Ikkita variant: > > 1. XAVFSIZ: push holatini ko‘rish uchun `git checkout ` orqali `view-last-push` tarmog‘ini yarataman — barcha ishni saqlayman, push qilingan holatni esa vaqtincha ko‘rsataman. > 2. BUZUVCHI: `git reset --hard ` — 4 ta commit va commit qilinmagan o‘zgarishlarni butunlay yo‘q qilaman. Ularni faqat 90 kun ichida `git reflog` orqali tiklash mumkin. Qaysi birini tanlaysiz? Bu — yo‘qolgan to‘rt soat o‘rniga yarim daqiqalik suhbat. ## Claude Code’da bekor qilishning 5 usuli qanday va to‘g‘risini qanday tanlash mumkin?
Asosiy xulosalar Biror narsa noto‘g‘ri ketsa, umidsizlik darajasi bo‘yicha beshta bosqich bor: `/rewind` (seans ichida), `git checkout .` (commit qilinmagan o‘zgarishlar), `git checkout ` (tarixni yo‘qotmasdan eski commitga qaytish), `git reset --hard ` (tarmoqni orqaga surish va undan keyingi commitlarni yo‘qotish), `git reflog` + tiklash (falokat — hammasi yo‘qolgan). Har bir keyingi daraja avvalgisidan og‘irroq va xavfliroq.
“Claude buzib qo‘ydi, zudlik bilan tiklashim kerak” degan holatda ushbu zinapoyadan eng pastidan boshlab harakat qiling. Har doim 1-darajadan boshlang. **1-daraja. `/rewind` — seans ichida darhol bekor qilish.** `Esc Esc` bosing yoki `/rewind` yozing. Buzilishdan oldingi nuqtani tanlang. Rejimni tanlang (odatda `Restore code and conversation`). Bir soniyadan so‘ng o‘tmishga qaytasiz va boshidan boshlashingiz mumkin. “Claude noto‘g‘ri ish qildi” holatlarining 80%ini qamrab oladi. **2-daraja. `git checkout .` — commit qilinmagan barcha o‘zgarishlarni bekor qilish.** ```bash git diff # avval aslida nima o‘zgarganini ko‘ring git checkout . # barcha fayllardagi commit qilinmagan o‘zgarishlarni bekor qilish # yoki tanlab: git checkout -- path/to/file.ts # faqat bitta fayl ``` `/rewind` ishlamaganida (masalan, Claude fayllarga bash orqali tegsa) yoki seans tarixidan tashqaridagi o‘zgarishlarni bekor qilish kerak bo‘lsa foydali. Commit qilinmagan barcha o‘zgarishlar butunlay yo‘qoladi. Bundan afsuslanishingiz mumkin bo‘lsa, avval `git stash`ni bajaring (2.5-darajaga qarang). **2.5-daraja. `git stash` — o‘zgarishlarni javonga qo‘yish.** ```bash git stash save "might still need this" # toza holatga qaytish (o‘zgarishlarsiz) # ... # fikringizdan qaytsangiz — stash'dan tiklang: git stash pop ``` “Abadiy yo‘qotish” va “o‘z holicha qoldirish” o‘rtasidagi yaxshi murosadir. Uni ochiqchasiga tozalamaguningizcha stash mahalliy holda qoladi. **3-daraja. `git checkout ` — tarixni yo‘qotmasdan eski commitga qaytish.** ```bash git log --oneline # to‘g‘ri commit xeshini toping, masalan, abc1234 git checkout abc1234 # ajratilgan HEAD — hech narsani o‘zgartirmay ko‘rish # holat ma’qul bo‘lsa, undan tarmoq yarating: git checkout -b recovery abc1234 # qaytish: git checkout main ``` Bu xavfsiz “vaqtinchalik qaytish”dir. Ajratilgan HEAD tarmoqni o‘zgartirmaydi; `main`dagi (yoki qaysi tarmoqda bo‘lgan bo‘lsangiz, o‘sha yerdagi) joriy ishingiz butun qoladi. Shu holat ustida ishlamoqchi bo‘lsangiz, tarmoq yarating. **4-daraja. `git reset --hard ` — tarmoqni ma’lum nuqtaga qaytarish.** ⚠️ Buzuvchi. Ko‘rsatilgan xeshdan keyingi commitlar yetim qoladi. ```bash git reflog # joriy holat xeshini yozib oling git reset --hard abc1234 # tarmoqni qayta yozish # xato topdingizmi? reflog orqali qayting: git reset --hard HEAD@{1} # resetdan oldingi holatga ``` Faqat oldindagi commitlar kerak emasligiga amin bo‘lsangiz foydalaning. Va fikringizdan qaytsangiz qayerga qaytishni bilish uchun resetdan OLDIN doim `git reflog`ni tekshiring. **5-daraja. `git reflog` + tiklash — halokatli vaziyat.** Kimdir (Claude, siz yoki hamkasbingiz) allaqachon `git reset --hard` yoki force-push qilib, ishni yo‘qotgan. Nima qilish kerak? ```bash git reflog # falokatdan oldingi oxirgi xeshni qidiring git branch recovered HEAD@{N} # undan tarmoq yarating git checkout recovered # unga o‘ting git diff main # joriy holat bilan solishtiring git checkout main && git merge recovered # ishonchingiz komil bo‘lsa, main’ga tiklang ``` Agar reflog allaqachon tozalangan bo‘lsa (odatda 90 kundan keyin), oxirgi chora — `.git/objects/` ichidagi osilib qolgan commitlarni ko‘rsatadigan `git fsck --lost-found` buyrug‘i. Bu deyarli arxeologiya, lekin ba’zan yordam beradi. **Darajani tanlash qoidasi:** | Nima yuz berdi | Daraja | |-----------------------------------------------|-----------------------------| | Claude 3 ta faylni noto‘g‘ri qayta yozdi | 1\. `/rewind` | | Sinab ko‘rdim, yoqmadi, seans yordam bermayapti | 2\. `git checkout .` | | Qo‘lda buzdim, yo‘qotishga ko‘nglim yo‘q, balki tiklayman | 2.5. `git stash` | | Commit qildim; bir commit ortga qaytishim kerak | 3\. `git checkout ` | | Oldindagi commitlar menga kerak emasligiga aminman | 4\. `git reset --hard` | | Buzuvchi buyruq bilan allaqachon yo‘qotdim | 5\. `git reflog` | ## Bekor qilishga hojat qolmasligi uchun loyihani qanday himoyalash mumkin?
Asosiy xulosalar Eng yaxshi bekor qilish — kerak bo‘lmaydigani. Uchta himoya qoidasi: har 30 daqiqada taraqqiyotni ko‘rib, ishlaydigan bosqichni faqat tekshirilgan yo‘llarni aniq stage qilib commit qiling; `.gitignore`ga kerakli `.claude/personal/` va `.env*` satrlarini kiriting; katta tajribalarni `git checkout -b experiment-` bilan alohida tarmoqda bajaring. Bu commit qilingan fayllar tiklash oralig‘ini toraytiradi; tashqi tizim va commit qilinmagan ishga alohida tiklash rejasi kerak.
**1-qoida. Har 30 daqiqada commit qiling.** “Vazifa tugadi” deb kutmang. Ishlaydigan har qanday oraliq qadamni commit qiling. Commit xabarlari qanday bo‘lishidan qat’i nazar, asosiysi Claude (yoki siz) bitta `git checkout` buyrug‘i bilan ishlaydigan holatga qayta olishingizdir. ```bash # vazifa boshida git status # staged va unstaged yo‘llarni ko‘ring git diff # tahrirlarni tekshiring # Misolni haqiqatan tekshirilgan fayl yo‘liga almashtiring. git add -- path/to/file.ts git diff --cached # commit tarkibini tasdiqlang git commit -m "wip: starting User schema migration" # 30 daqiqadan keyin (yoki birinchi ishlaydigan takrorlashdan so‘ng) git status git diff git add -- path/to/file.ts # haqiqiy tekshirilgan yo‘l; wildcard emas git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # vazifa oxirida — mazmunli commit git reset --soft HEAD~2 # uchta wip commitni bittaga birlashtiring git commit -m "feat(auth): add lastLoginAt field to User table" ``` PostToolUse eslatmasi qo‘shsangiz, ko‘rik va aniq yo‘l staging qoidasini saqlang. Taymerni tekshirilmagan auto-commit’ga aylantirmang: begona tahrir yoki avval staged fayl commit’ga kirishi mumkin. **2-qoida. Minimal `.gitignore`.** Loyiha ildizida quyidagi satrlar bo‘lishi shart: ```gitignore # maxfiy ma’lumotlar .env .env.local .env.*.local # mahalliy Claude Code sozlamalari (jamoa omboriga push qilinmaydi) .claude/personal/ .claude/sessions/ .claude/file-history/ # bog‘liqliklar va yig‘ish natijalari node_modules/ dist/ .next/ build/ ``` Men `.claude/personal/` papkasini shaxsiy tajribalarim va qaydlarim uchun saqlayman, u umumiy omborga kiritilmasligi kerak. `.claude/sessions/` va `.claude/file-history/` papkalari Claude Code’ning mahalliy xotirasidir; ular omborga tegishli emas, ko‘p joy egallaydi va muayyan mashinaga bog‘langan. **3-qoida. Tajribalarni alohida tarmoqda bajaring.** Vazifa katta bo‘lsa (10+ faylni refaktorlash, yangi ma’lumotlar bazasiga o‘tish, modulni qayta yozish), uni asosiy tarmoqda bajarmang: ```bash git checkout -b experiment/auth-rewrite # ishlang, har 30 daqiqada commit qiling # ishlasa: git checkout main git merge experiment/auth-rewrite # ishlamasa: git checkout main git branch -D experiment/auth-rewrite # tarmoqni o‘chirish # tamom, asosiy tarmoq butun qoladi ``` Bu oddiy odat “Claude loyihani vayron qildi” holatini “Claude bitta tarmoqni vayron qildi, men uni o‘chirdim va boshidan boshladik” holatiga aylantiradi. **4-qoida. Xavfli amallardan oldin `git tag` ishlating.** Ma’lumotlar bazasi migratsiyasi, katta refaktorlash yoki bog‘liqliklarni yangilashdan oldin teg yarating: ```bash git tag pre-prisma-migration-v2 # ishlang # nimadir noto‘g‘ri ketsa: git reset --hard pre-prisma-migration-v2 # yoki shunchaki ko‘ring: git checkout pre-prisma-migration-v2 ``` Teg — reflog tozalanganidan keyin ham yo‘qotmaydigan commitga nomlangan ko‘rsatkich. ## Keyingi mavzu: bekor qilish kontekst muhandisligiga qanday kiradi?
Asosiy xulosalar Bekor qilish alohida ko‘nikma emas, Claude Code seansi kontekstini boshqarishning bir qismidir. Qachon `/rewind` bosish, qachon `git commit` qilish va qachon `git stash` ishlatishni bilsangiz, bitta buyruqni emas, butun ish jarayonini boshqarasiz. Bu **Kontekst muhandisligi**ning bir qismidir. Usiz Claude oddiy yordamchidek, u bilan esa bashoratli vositadek ishlaydi.
Bekor qilishning bu uch darajasi buzilish yuz berganda holatni tiklash ko‘nikmasining infratuzilmasidir. Bu ko‘nikmaning o‘zi tor doirada. Ammo boshqa kontekst muhandisligi vositalari bilan qo‘shilganda, u yanada muhim narsaga aylanadi. Plan Mode kodni darhol yozishga ruxsat bermaydi — avval reja, keyin tasdiq, so‘ng bajarish keladi. Bu profilaktik bekor qilishdir: reja oldindan ko‘rib chiqilgani uchun keyin bekor qilishingizga to‘g‘ri keladigan narsani yozmaysiz. Batafsil ma’lumotni [Claude Code’dagi Plan Mode](https://ailoot.ai/blog/uz/claude-code-plan-mode/) qo‘llanmasidan o‘qing. [CLAUDE.md](https://ailoot.ai/blog/uz/claude-md-template/) Claude odatda amal qiladigan qoidalarni belgilaydi, jumladan, yuqorida ko‘rib chiqqan Git xavfsizlik protokolini. Bu buzuvchi buyruqlardan profilaktik himoyadir. [Ikkinchi miya](https://ailoot.ai/blog/uz/claude-code-second-brain/) Claude’ga seanslar oralig‘ida loyiha xotirasini beradi — u qanday kod borligini, biznes mantiqi nimadan iboratligini va avval qanday kelishuvlar qilinganini biladi. Xotira qancha ko‘p bo‘lsa, noto‘g‘ri ish qilish ehtimoli shuncha kam. [Skills va subagentlar](https://ailoot.ai/blog/uz/claude-code-skills-library/) — metodologiyangizning koddagi ifodasidir. To‘g‘ri git ish jarayoni Skill’ga kiritilgan bo‘lsa, hech bir subagent tasdiqsiz `git reset --hard` bajarmaydi. Bularning barchasi birgalikda **Kontekst muhandisligi**dir. So‘rov vaqtida emas, undan oldin kontekstni boshqaring. Batafsil ma’lumotni [kontekst muhandisligi nima](https://ailoot.ai/blog/uz/context-engineering/) maqolasidan o‘qing. Bekor qilish — oxirgi himoya chizig‘i. Plan Mode + CLAUDE.md + Ikkinchi miya + Skills — dastlabki to‘rtta himoya chizig‘i. Ular sozlangan bo‘lsa, bekor qilish kam va tez-tez emas. Sozlanmagan bo‘lsa, bu kundalik odatga aylanadi.
### Manbalar - [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)
Rejalarni tuzish tugagan joydan bekor qilish boshlanadi. [Ailoot’ni oching](https://ailoot.ai/). ## Ko‘p beriladigan savollar ### WIP checkpoint uchun git add . ishlatiladimi? Yo‘q. `git status` va `git diff` ni ko‘ring, faqat nomi bilan tekshirilgan fayllarni stage qilib, `git diff --cached` ni ko‘ring. Davriy checkpoint begona yoki oldin staged qilingan o‘zgarishni qo‘shishga ruxsat bermaydi. ### /rewind baza migratsiyasi yoki tashqi API amalini qaytaradimi? Yo‘q. Checkpoint seansdagi qo‘llanadigan fayl tahrirlari bilan cheklangan. Baza, remote Git va API ta’sirlariga alohida tiklash kerak. Qamrovdan tashqari fayllarda Git yoki zaxira ishlating. ## Ailoot · Kompaniya va uning loyihalar portfeli Ailoot to‘plangan faoliyat tajribasi, keng mijozlar bazasi, barqaror xizmat va doimiy KPI nazoratiga tayanadi. Kompaniya va uning loyihalar portfeli: millionlab mijozlar; oylik sotuvlar hajmi milliardlarda. Ailoot bu faoliyat tajribasini mijozlar mahsulotlari, agentlar, ilovalar va avtomatlashtirishlarda AI imkoniyatlariga API orqali kirishni ta’minlashda qo‘llaydi.