# Claude Code-тағы өзгерістерді қалай қайтаруға болады: /rewind және git

> Қайтару режимдері, бақылау нүктелерінің шектеулері, git checkout, stash, reflog және деструктивті командалардан қорғану. Күйді қалпына келтірудің бес тәсілі.

Source: https://ailoot.ai/blog/kk/claude-code-undo-changes/
Canonical: https://ailoot.ai/blog/kk/claude-code-undo-changes/
Language: kk
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-138
Revision: sha256-9dae10edbe8f731321d59aa398ce512555d91264c7ce8c300a3b0749a33344a9




Ailoot-пен жұмыс істеу туралы практикалық ақпаратты [құжаттамадан](https://ailoot.ai/docs/) таба аласыз.

## Claude Code-тағы қайтару деген не және неге үш деңгей жеткіліксіз?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Claude Code-та қайтарудың үш деңгейі бар: кірістірілген `/rewind` командасы (сеанс ішінде лезде қалпына келтіру), `git checkout` (соңғы коммитке қайту) және `git reflog` (`git reset --hard` орындалған жағдайда апаттан сақтандыру құралы). Әр деңгей өз қателер тобын қамтиды және белгіленген шегінен аспайды. Тек `/rewind` пәрменін білу алғашқы күрделі қателікте қорғансыз қалдырады.

</div>

Claude Code-ты қолдана бастаған алғашқы аптамда `/rewind` пәрменін қостым: ол екі сұраудан кейін жобамның аутентификация логикасын бұзды. Қайтардым, демімді бастым да, жұмысымды жалғастырдым. Бір айдан кейін тағы бір жағдай болды: схема миграциясын жазып жүрдім, Claude көмектесті, коммит жасап, тармақтарды ауыстырдым да, бір қажетті қадамды ұмытып кеткенімді түсіндім. `/rewind` көмектеспеді — сеанс әлдеқашан басқа еді. Алдыңғы коммитке `git checkout` жасау көмектесті. Одан бір ай өткен соң агентке байқамай «бәрін соңғы push-қа дейін кері қайтар» деп айтып қойдым, ол `git reset --hard` орындап, үш сағаттық жұмысымды құртып жіберді. `git reflog` құтқарды — жойылған коммиттердің хэштері әлі сақтаулы еді.

Бұл үш оқиға — әртүрлі жұмыс істейтін, әртүрлі қателерді ұстайтын және үшеуі де қажет қорғаныстың үш деңгейі. Бұл нұсқаулықта әр деңгейдің командалары, шектеулері мен мысалдары түсіндіріледі. Сондай-ақ Claude бірінші рет жобаны құлатпауы үшін жобаны алдын ала қалай баптау керегі көрсетіледі.

**Қайтарудың 3 деңгейі — нені және қашан қолдану керек:**

| Деңгей | Команда | Қамтитын жағдайлар | Қамтымайтын жағдайлар |
|----|----|----|----|
| 1\. Сеанс ішінде | `/rewind` немесе `Esc Esc` | Claude өз құралдары арқылы өзгерткен файлдар; әңгіме тарихы | Bash командалары, сыртқы редакторлар, дерекқор миграциялары |
| 2\. Коммитке дейін | `git checkout .` немесе `git stash` | Файлдардағы барлық коммиттелмеген өзгерістер | Коммиттелген коммиттер |
| 3\. Апат жағдайы | `git reflog` + `git reset --hard <hash>` | `reset --hard` не force-push жойған коммиттер | Деструктивті bash командалары (rm, дерекқор миграциялары) |

Әрі қарай әр деңгей бойынша нақты не істеу керегін, қандай тұзақтар барын және ештеңе бұзылмағандықтан қайтаруға да тура келмейтіндей етіп қалай баптау керегін қарастырамыз.

## /rewind пәрменін қалай шақырасыз: командамен бе, әлде Esc-Esc пернелерімен бе?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Claude Code-та Rewind мәзірін ашудың екі жолы бар. Біріншісі — енгізу өрісіне `/rewind` деп жазу. Екіншісі — енгізу өрісі бос кезде `Esc` пернесін екі рет басу. Өрісте мәтін болса, Esc-ті екі рет басу алдымен оны өшіріп, енгізу тарихына сақтайды; мәзірді ашу үшін тағы бір рет екі рет басу керек. `/rewind` командасының бүркеншік атауы — `/checkpoint`.

</div>

Әр жауаптан кейін Claude сол сеанста өзі өңдеген барлық файлдың суретін автоматты түрде түсіреді. Суреттер `~/.claude/file-history/{sessionId}/` ішінде сақталып, 30 күнге дейін ұсталады. Суреттер инкременттік: бүкіл файл емес, күйлер арасындағы айырмашылықтар ғана сақталады. Әдепкіде әр сеанста 100-ге дейін сурет сақталады. Демек, нақты жобалардың көбінде жұмыс күні бойы Claude жасаған барлық өзгерістің толық тарихы кез келген сәтте қолжетімді болады.

Кері қайтару мәзірін ашу үшін енгізу өрісі бос кезде `Esc` пернесін екі рет басыңыз:

```
[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)
  ...
```

Енгізу өрісінде мәтін болса, `Esc` пернесін алғаш екі рет басқанда ол өшіріліп, `Up` тарихына сақталады. Бұл мәтін тере бастап, кейін кері қайту керек екенін түсінгенде пайдалы. Anthropic-тің ресми құжаттамасынан дәйексөз:

<figure>
<blockquote>
<p>Егер сұрау өрісінде мәтін болса, Esc пернесін екі рет басқанда мәзір ашылмай тұрып, мәтін алдымен өшіріледі. Өшірілген мәтін енгізу тарихына сақталады, сондықтан кері қайтару мәзірінен кейін жоғары көрсеткі пернесі арқылы оны қалпына келтіруге болады.</p>
</blockquote>
<figcaption>— Anthropic құжаттамасы, https://code.claude.com/docs/en/checkpointing</figcaption>
</figure>

`/rewind` командасы да дәл осыны істейді — мәзірді ашады. Оған апаратын `/checkpoint` бүркеншік атауы да бар. Қай тәсіл ыңғайлы екені әдетке байланысты. Мен `Esc Esc` қолданамын — ол жылдамырақ әрі қолымды пернетақтадан алмаймын.

## Rewind мәзіріндегі 6 режим: қайсысын және қашан таңдау керек?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Rewind мәзірінен қайтару нүктесін таңдаған соң, алты режимі бар екінші мәзір шығады. Үшеуі күйді қалпына келтіреді (`Restore code and conversation`, `Restore conversation`, `Restore code`), екеуі тарихты ықшамдайды (`Summarize from here`, `Summarize up to here`), ал біреуі әрекеттен бас тартады (`Never mind`). Ең жиі кездесетін «код пен әңгімені қатар қайтару» жағдайында бірінші нұсқа таңдалады.

</div>

Тізімнен нүктені таңдасаңыз, әрекеттер мәзіріне өтесіз. Онда әрқайсысы әртүрлі әрекет орындайтын алты тармақ бар.

**Режимдердің толық кестесі:**

| Режим | Не істейді | Қай кезде таңдау керек |
|----|----|----|
| `Restore code and conversation` | Файлдар мен әңгіме тарихын таңдалған нүктедегі күйге қайтарады | Ең жиі кездесетін жағдай: Claude қате бағытқа кетті, мен дұрыс тұжырыммен қайта бастағым келеді |
| `Restore conversation` | Тек әңгіме тарихын кері қайтарады; файлдар қазіргі күйінде қалады | Код дұрыс, бірақ әңгіме басқа арнаға ауытқыды; қазіргі өзгерістерді сақтап, осы жерден ойымды басқаша тұжырымдаймын |
| `Restore code` | Файлдарды кері қайтарады; әңгіме сол күйінде қалады | Claude өзгерістерінің кейбірі қажетсіз болды, бірақ әңгіме контексті әлі керек (мысалы, келесі қадамдарды келіскенбіз) |
| `Summarize from here` | Таңдалған нүктеден КЕЙІНГІ бүкіл мазмұнды қысқаша түйінге айналдырады. Файлдарға тимейді | Ұзақ жөндеу сеансы контексті тауысты; бастапқы нұсқауларды толық сақтай отырып, орын босату керек |
| `Summarize up to here` | Таңдалған нүктеге ДЕЙІНГІ бүкіл мазмұнды қысқаша түйінге айналдырады. Файлдарға тимейді | Алғашында ұзақ нұсқаулық, одан кейін нақты тапсырма болды — нұсқаулықты бір хабарламаға ықшамдап, соңғы жұмысты сол күйінде қалдырамыз |
| `Never mind` | Ештеңені өзгертпей мәзірді жабады | Ойымнан айныдым |

`Summarize up to here` мүмкіндігі Claude Code v2.1.139-v2.1.142 нұсқаларында, 2026 жылғы 11–15 мамырда, 20-аптада шықты:

<figure>
<blockquote>
<p>Rewind мәзіріндегі 'Summarize up to here' пәрмені арқылы бастапқы контексті ықшамдауға болады.</p>
</blockquote>
<figcaption>— Anthropic жаңалықтары, https://code.claude.com/docs/en/whats-new</figcaption>
</figure>

`Restore` мен `Summarize` арасындағы айырмашылық түбегейлі. Restore алдыңғы күйге қайтарып, таңдалған нүктеден кейін болғанның бәрін болдырмайды. Summarize ештеңені болдырмайды, тек ықшамдайды: бастапқы хабарлар анықтама үшін сеанс транскриптінде қалады, бірақ белсенді контексте тек қысқаша түйін тұрады. «Бұл мүлде болмағандай» күйге келтіру керек болса, restore қолданыңыз. «Қалсын, бірақ контекст орнын алма­сын» десеңіз, summarize қолданыңыз.

`Restore conversation` немесе `Summarize from here` пәрменінен кейін таңдалған сұраудың бастапқы мәтіні енгізу өрісіне қайтады — оны өңдеп, қайта жібере аласыз. `Summarize up to here` пәрменінен кейін енгізу өрісі бос қалады да, әңгіменің соңында тұрасыз.

## /rewind қандай өзгерістерді ҚАЙТАРМАЙДЫ?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

`/rewind` тек Claude-тың өз файл өңдеу құралдары арқылы жасаған өзгерістерін бақылайды. Басқасын көрмейді әрі қалпына келтіре алмайды. Көрінбейтін өзгерістердің үш санаты бар: bash командалары (rm, mv, cp), сыртқы өңдеулер (IDE-дегі қолмен жасалған түзетулер, басқа сеанстардан келген өзгерістер) және файлдардан тыс операциялар (дерекқор миграциялары, git push, қашықтағы API шақырулары).

</div>

Бұл — адамдар жиі ұшырасатын басты шектеу: `/rewind` жасыл құсбелгі көрсетіп, «қайтару сәтті аяқталды» дейді, бірақ жоба әлі бұзылған, өйткені Claude файлдардан басқа нәрселерді де өзгерткен. Үш жағдайды қарастырайық.

**1. Bash командалары бақыланбайды.** Егер Claude бір айналымда `rm file.txt` немесе `mv old.txt new.txt` орындаса, бұл өзгерістер бақылау нүктесіне кірмейді. Anthropic құжаттамасында бұл анық жазылған:

<figure>
<blockquote>
<p>Бақылау нүктелері bash командалары арқылы өзгертілген файлдарды қадағаламайды. Мысалы, Claude Code `rm file.txt`, `mv old.txt new.txt`, `cp source.txt dest.txt` командаларын орындаса, бұл файл өзгерістерін кері қайтару арқылы болдырмау мүмкін емес.</p>
</blockquote>
<figcaption>— Anthropic құжаттамасы, https://code.claude.com/docs/en/checkpointing</figcaption>
</figure>

Яғни Claude bash құралын қолданып файлды өзі жойса, жылжытса не көшірсе, `/rewind` бәрін қалпына келтірмейді. `git checkout` немесе сақтық көшірмеден қалпына келтіру көмектесуі мүмкін, бірақ ол үшін екі пернені басудан көбірек әрекет керек.

**2. Сыртқы өңдеулер ескерілмейді.** VS Code-та файлды қолмен ашып, бір нәрсені өзгертсеңіз немесе екінші Claude сеансы дәл сол файлдарды қатар өзгертсе, бірінші сеанс ол өзгерістерді көре алмайды. Бақылау нүктесінің суреті Claude ағымдағы сеанста кезекті аяқтағанда түсіріледі. Кезектер арасында болған әрекеттер оның жауапкершілігіне кірмейді.

**3. Файлдардан тыс операциялар мүлде қамтылмайды.** `npx prisma migrate dev` арқылы қолданылған Prisma миграциясы дерекқор схемасын өзгертті — `/rewind` оны болдырмайды, себебі дерекқор жобаның файлдық жүйесінен тыс. `origin/main` тармағына force-push жасау да сондай: коммит қашықтағы серверге жіберілді, ал бақылау нүктесі оны қайтармайды. Ақша алған немесе жазбаны жойған қашықтағы API шақыруын тек сол API-дің өз тетіктері арқылы болдырмауға болады.

**Ереже:** тапсырма жоба файлдарынан тыс нәрсеге әсер етсе — дерекқор миграциялары, git push, қашықтағы API-лер — әр сыртқы әсерге жеке қайтару стратегиясын дайындаңыз. `/rewind` — ағымдағы сеанс ішіндегі жергілікті файлдар тарихы ғана.

## /rewind пен git-тің айырмашылығы неде және неге екеуі де керек?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

`/rewind` — бір Claude Code сеансы ішіндегі жергілікті кері қайтару. Ол инкременттік суреттерді 30 күнге дейін, әр сеанста 100-ге дейін сақтайды. git — тармақтары, біріктіру қақтығыстары және қашықтағы репозиторийі бар, командаға ортақ жобаның ұзақ мерзімді тарихы. Бірі екіншісін алмастырмайды. Ең дұрыс тәсіл — әр логикалық кезеңде `git commit` жасап, коммиттер арасында `/rewind` қолдану.

</div>

Anthropic құжаттамасында бұл үйлесім тікелей айтылған:

<figure>
<blockquote>
<p>Бақылау нүктелері сеанс деңгейінде жылдам қалпына келтіруге арналған. Коммиттер, тармақтар және ұзақ мерзімді тарих үшін Git сияқты нұсқаларды бақылау жүйесін қолдануды жалғастырыңыз. Бақылау нүктелері қалыпты нұсқаларды бақылауды толықтырады, бірақ алмастырмайды. Бақылау нүктелерін «жергілікті қайтару», ал Git-ті «тұрақты тарих» деп қарастырыңыз.</p>
</blockquote>
<figcaption>— Anthropic құжаттамасы, https://code.claude.com/docs/en/checkpointing</figcaption>
</figure>

Айырмашылықтар бір кестеде:

| Параметр | /rewind | git |
|----|----|----|
| Түйіршіктілігі | Әңгімедегі әр кезек | Әр коммит |
| Сақтау | 30 күнге дейін, әр сеанста 100-ге дейін, жергілікті `~/.claude/file-history/` ішінде | Репозиторийдің `.git/` бумасында және қашықтағы серверде тұрақты сақталады |
| Нені бақылайды | Claude-тың өз құралдары арқылы жасаған түзетулерін | Барлық коммиттелген өзгерістерді |
| Нені бақылай алмайды | Bash, сыртқы өңдеулер, миграциялар, push | Коммиттелмеген өзгерістерді |
| Команда | Claude ішіндегі команда | Сыртқы нұсқаларды бақылау жүйесі |
| Әңгімені кері қайтара ма | Иә | Жоқ |
| Сеанстар арасында жұмыс істей ме | Тек сол сеанс ішінде | Барлық жерде |

Үйлесім қарапайым: «мынау жұмыс істеп тұр, оны жоғалтқым келмейді» деген күйге жеткенде `git commit` жасаңыз. Коммиттер арасында `/rewind` қолданыңыз — ол лезде орындалады, коммит хабарын талап етпейді және git тарихын аралық күйлермен толтырмайды. Жұмыс біткенде, мағыналы әрі мүмкіндігінше тұтас коммит жасаңыз.

## Неге бір /rewind бүкіл тапсырманы қамтымайды?

Қайтару — **контекст инженериясының** бір бөлігі. Сеанс контекстін басқарсаңыз (қашан коммит жасау, қашан `/rewind` басу, `CLAUDE.md` файлына қандай ережелер енгізу), Claude-тың мінезі болжамды болып, жобаңызды құлатпайды және жұмысыңызды жоғалтпайды.



## Claude-тан «кері қайтаруды» сұрағанда `git reset --hard` неге қауіпті?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Табиғи тілдегі «кері қайтару» тарихқа қарауды білдіреді, оны жоюды емес; Claude әдепкіде `reset --hard` емес, `git checkout` ұсынуы керек; қорғанысты CLAUDE.md ішінде баптауға болады.

</div>

«Ағымдағы күйді сақтап, соңғы push-қа дейін кері қайтару» туралы сұрау мына командаларға әкелуі мүмкін:

```bash
git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # коммиттелмеген өзгерістер сақталды
git reset --hard 35eb731                                                # d63695e..882e618 коммиттері жойылды
```

Бірінші команда дұрыс болды — коммиттелмеген өзгерістер stash ішінде сақталды. Екіншісі деструктивті еді: ол тармақты `35eb731` коммитіне қайта жазып, одан `882e618` коммитіне дейінгі коммиттердің бәрін қолжетімсіз етті. Әдепкіде orphan коммиттер `git gc` іске қосылғанша `.git/objects/` ішінде қалады; бұл әдетте екі апта ішінде автоматты түрде орындалады. Бірақ сол сәтте не істеу керегін білмесеңіз, уақыт сізге қарсы жұмыс істей бастайды.

Логика қарапайым: табиғи тілдегі «кері қайтар», «артқа бар», «қалпына келтір», «revert жаса» және «болдырма» деген сөздер «тарихты қара» немесе «қауіпсіз орынға қайт» дегенді білдіреді. Олар «тарихты жой» деген мағына бермейді. `git reset --hard` тарихты жояды — тармақты қайта жазып, HEAD арқылы қолжетімді коммиттерді алып тастайды. Қауіпсіз балама — `git checkout <commit>`: ол detached HEAD жасап, тармақтарға тимей ескі күйді көруге мүмкіндік береді.

Негізгі практикалық тұжырым — кез келген үлкен тапсырманың алдында, әсіресе бірнеше файлды рефакторинг жасаудан бұрын, ағымдағы күйге `git commit` жасау. Бір коммит кез келген Claude қатесін жұмысты жоғалтпай, бір `git checkout .` командасымен қайтаруға мүмкіндік береді.

## Деструктивті reset-тен кейін git reflog қалай құтқарады?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

`git reflog` репозиторийдегі HEAD қозғалыстарының жергілікті тарихын көрсетеді, соның ішінде `git reset --hard` немесе force-push арқылы жойылған коммиттер де бар. Әр қозғалыс әдепкіде 90 күн сақталады. Егер Claude (не сіз, не басқа біреу) деструктивті командамен коммиттерді жойса, `git reflog` олардың хэштерін көрсетеді, ал `git reset --hard <reflog-hash>` арқылы тармақты қалпына келтіруге болады.

</div>

Деструктивті reset-тен кейін бірден `git reflog` орындаңыз:

```bash
git reflog
```

Шығыс мынадай болады:

```
35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main
```

`HEAD@{1}` пен `HEAD@{3}` — дәл сол «жойылған» коммиттер. Олар git-тің жергілікті объектілер қоймасынан жоғалған жоқ; тек тармақ арқылы қолжетімсіз болып қалды. Оларды қалпына келтіру үшін:

```bash
# Соңғы “жойылған” коммиттен тармақ жасау
git branch recovered-work 882e618

# Немесе тікелей ауысу
git reset --hard 882e618
```

Осыдан кейін тармақ апатқа дейінгі бүкіл тарихты қайта қамтиды.

**Reflog шектеулері:**

1.  **Тек жергілікті.** Reflog `.git/logs/HEAD` ішінде сақталады; қашықтағы репозиторийде болмайды. Force-push жасап, жергілікті репо көшірмесін жойсаңыз, reflog те сол бумамен бірге кетеді.
2.  **Әдепкіде 90 күн.** Ескі жазбалар git gc кезінде жойылуы мүмкін. Мерзімді `git config gc.reflogExpire 200.days.ago` командасымен баптауға болады.
3.  **HEAD-та ешқашан болмаған нәрсені қамтымайды.** Егер коммит тек stash ішінде болып, stash жойылса, reflog оның ішкі тарихын емес, тек stash-тің соңғы күйін көрсетеді.

**Команда ережесі:** апаттан кейін бірден `git gc --aggressive` ешқашан орындамаңыз. Алдымен reflog арқылы тексеріп, қалпына келтіріңіз; қалғанының бәрін кейін жасаңыз. Қажеттінің бәрі жіберілгеніне көз жеткізбейінше жергілікті репозиторий көшірмесін ешқашан жоймаңыз.

## CLAUDE.md арқылы жобаны деструктивті git командаларынан қалай қорғайсыз?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Жобаңыздың `CLAUDE.md` файлына Claude өзі орындай алатын, нақты растауды қажет ететін және пайдаланушы нақты тіркесті айтпайынша тыйым салынатын git командаларын белгілейтін нұсқаулар блогын қосыңыз. Claude әдетте CLAUDE.md файлын жобаның жүйелік сұрауы ретінде қабылдап, осы ережелерді ұстанады. Бұл бір «қауіпті» сұрауды екі қауіпсіз командаға айналдырады.

</div>

Осалдықтың себебі — Claude-та әдепкіде қорғаныс контексті жоқ. Ол «кері қайтар» дегенді `git reset --hard` деп түсінеді, өйткені техникалық жағынан бұл жарамды тәсіл. Қорғанысты жобаның жүйелік сұрауы саналатын `CLAUDE.md` файлына енгізіңіз.

**Минималды ереже** (`CLAUDE.md` файлыңызға қосыңыз):

```markdown
## Git Safety Protocol

- Мен бұл әрекеттерді нақты сұрамайынша, деструктивті git командаларын (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) ЕШҚАШАН орындамаңыз. Рұқсатсыз деструктивті әрекеттер пайдасыз әрі жұмыстың жоғалуына әкелуі мүмкін.
- Мен "roll back", "go back", "restore", "revert", "undo" дегенде, мұны HISTORY командаларын шолу деп түсініңіз: `git log`, `git diff`, `git checkout <commit>` (detached HEAD жасайды) немесе `git stash` (өзгерістерді сақтайды) қолданыңыз.
- МЫНА командалардың КЕЗ КЕЛГЕНІН орындамас бұрын ӘРҚАШАН растауды сұраңыз:
  - HEAD орнын тармақтағы басқа коммитке өзгертсе
  - Коммит тарихын өзгертсе
  - Коммиттелмеген жұмысты жоғалтуы мүмкін болса
  - --hard, --force, --aggressive жалаушаларын қамтыса
- Кез келген деструктивті команданың алдында нөмірленген салыстыруды көрсетіңіз:
  - ҚАУІПСІЗ: уақытша көру үшін `git checkout <commit>` қолданыңыз
  - ДЕСТРУКТИВТІ: біржола жою үшін `git reset --hard` қолданыңыз
- Орындамас бұрын менің нақты таңдауымды күтіңіз.
```

**Топқа арналған кеңейтілген ереже** (репозиторий түбіріндегі `CLAUDE.md` файлына қосыңыз):

```markdown
## Git Workflow Rules

- Әр жұмыс істейтін кезеңде коммит жасаңыз. WIP коммитіне дейін `git status` пен `git diff` орындап, тек қарап шыққан атаулы файлдарды `git add -- path/to/file` арқылы қосыңыз, кейін индекстегі diff-ті қарап коммиттеңіз. Таймер — бүкіл жұмыс ағашын қосуға рұқсат емес, тексеру еске салғышы.
- Claude коммит жасау үшін ешқашан `git add .` немесе `git add -A` қолданбасын. Тек `git status` + `git diff` тексергеннен кейін файлдарды атымен нақты көрсетіңіз.
- main тармағына `git push --force` жасамас бұрын тоқтап, менен сұраңыз. Функция тармақтарында алдыңғы нұсқаны жоғалтуға келісетініме сенімді болсаңыз ғана абайлап force-push жасаңыз.
- Біріктіру қақтығыстарын шешкенде, бірден "ours" немесе "theirs" таңдамаңыз — алдымен екі нұсқаны да көрсетіңіз, содан кейін мен шешемін.
- `.gitignore` ішінде `.env*`, `.claude/personal/`, `node_modules/`, `dist/` болуы керек. Біреуі жоқ болса, қосыңыз.
```

Осы блоктарды қосқаннан кейін, «соңғы push-қа дейін кері қайтар» деген келесі өтінішке жауап мынадай болар еді:

> Коммиттелмеген 3 файл және соңғы push-тан кейінгі 4 коммит бар екенін көріп тұрмын. Екі нұсқа:
>
> 1.  ҚАУІПСІЗ: `git checkout <last-push-hash>` арқылы `view-last-push` тармағын жасаймын — барлық жұмысты сақтаймын, бірақ push жасалған күйді уақытша көрсетемін.
> 2.  ДЕСТРУКТИВТІ: `git reset --hard <last-push-hash>` — 4 коммит пен коммиттелмеген өзгерістерді біржола жоямын. Оларды 90 күн ішінде тек `git reflog` арқылы қалпына келтіруге болады. Қайсысын таңдайсыз?

Бұл — төрт сағат жоғалтқаннан гөрі жарты минут сөйлесу.

## Claude Code-та қайтарудың 5 тәсілі қандай және дұрысын қалай таңдайсыз?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Бірдеңе дұрыс болмаса, шарасыздықтың бес деңгейі бар: `/rewind` (сеанс ішінде), `git checkout .` (коммиттелмеген өзгерістер), `git checkout <commit>` (тарихты жоғалтпай ескі коммитке оралу), `git reset --hard <commit>` (тармақты кері жылжытып, одан кейінгі коммиттерден айырылу), `git reflog` + қалпына келтіру (апат, бәрі жоғалған). Әр деңгей алдыңғысынан салмақтырақ әрі қауіптілеу.

</div>

«Claude бұзып жіберді, шұғыл қалпына келтіруім керек» деген жағдай осы баспалдақпен төменнен жоғары қарай шешіледі. Әрдайым 1-деңгейден бастаңыз.

**1-деңгей. `/rewind` — сеанс ішіндегі лезде қайтару.**

`Esc Esc` пернелерін басыңыз немесе `/rewind` деп жазыңыз. Бұзылуға дейінгі нүктені таңдаңыз. Режимді таңдаңыз (әдетте `Restore code and conversation`). Бір секундтан соң өткенге ораласыз да, қайта бастай аласыз. «Claude дұрыс емес нәрсе істеді» деген жағдайлардың 80%-ын қамтиды.

**2-деңгей. `git checkout .` — коммиттелмеген барлық өзгерісті болдырмау.**

```bash
git diff                    # алдымен нақты не өзгергенін көріңіз
git checkout .              # барлық файлдағы коммиттелмеген өзгерістерді болдырмау
# немесе таңдап:
git checkout -- path/to/file.ts   # бір ғана файл
```

`/rewind` көмектеспегенде (мысалы, Claude файлдарға bash арқылы тигенде) немесе сеанс тарихынан тыс өзгерісті болдырмау қажет болғанда пайдалы. Коммиттелмеген барлық өзгеріс біржола жоғалады. Кейін өкінуіңіз мүмкін болса, алдымен `git stash` орындаңыз (2.5-деңгейді қараңыз).

**2.5-деңгей. `git stash` — өзгерістерді сөреге қою.**

```bash
git stash save "might still need this"
# таза күйге оралу (өзгерістерсіз)
# ...
# ойыңызды өзгертсеңіз — stash-тен қалпына келтіріңіз:
git stash pop
```

«Біржола жоғалту» мен «сол күйі қалдырудың» арасындағы жақсы ымыра. Stash жергілікті күйде, арнайы тазаланғанша сақталады.

**3-деңгей. `git checkout <commit>` — тарихты жоғалтпай ескі коммитке оралу.**

```bash
git log --oneline               # дұрыс коммиттің хэшін табыңыз, мысалы abc1234
git checkout abc1234            # detached HEAD — ештеңені өзгертпей қарау
# күй дұрыс болса, одан тармақ жасаңыз:
git checkout -b recovery abc1234
# қайту:
git checkout main
```

Бұл — қауіпсіз «уақытша оралу». Detached HEAD тармақты өзгертпейді; `main` тармағындағы (немесе қай тармақта болсаңыз да) қазіргі жұмысыңыз сақталады. Осы күйде жұмыс істегіңіз келсе, одан тармақ жасаңыз.

**4-деңгей. `git reset --hard <commit>` — тармақты белгілі бір нүктеге жылжыту.**

⚠️ Деструктивті. Көрсетілген хэштен кейінгі коммиттер orphan күйіне түседі.

```bash
git reflog                                  # ағымдағы күйдің хэшін жазып алыңыз
git reset --hard abc1234                    # тармақты қайта жазыңыз
# қателескеніңізді таптыңыз ба? reflog арқылы қайтыңыз:
git reset --hard HEAD@{1}                   # reset-ке дейінгі күйге
```

Одан кейінгі коммиттер қажет емес екеніне сенімді болсаңыз ғана қолданыңыз. Ойыңызды өзгертсеңіз қайда қайтатыныңызды білу үшін reset алдында міндетті түрде `git reflog` тексеріңіз.

**5-деңгей. `git reflog` + қалпына келтіру — апатты жағдай.**

Біреу (Claude, сіз немесе әріптесіңіз) `git reset --hard` не force-push орындап, жұмысты өшіріп тастады. Не істейсіз?

```bash
git reflog                                          # апатқа дейінгі соңғы хэшті іздеңіз
git branch recovered HEAD@{N}                       # сол хэштен тармақ жасаңыз
git checkout recovered                              # соған ауысыңыз
git diff main                                       # ағымдағы күймен салыстырыңыз
git checkout main && git merge recovered            # сенімді болсаңыз, main ішіне қалпына келтіріңіз
```

Reflog тазартылып қойса (әдепкіде 90 күннен кейін), соңғы шара — `.git/objects/` ішіндегі dangling коммиттерді көрсететін `git fsck --lost-found`. Бұл археологияға жақын, бірақ кейде көмектеседі.

**Деңгейді таңдау ережесі:**

| Не болды | Деңгей |
|-----------------------------------------------|-----------------------------|
| Claude 3 файлды қате жолмен қайта жазды | 1\. `/rewind` |
| Байқап көрдім, ұнамады, сеанс көмектеспей тұр | 2\. `git checkout .` |
| Қолмен бұздым, жоғалтқым келмейді, қайта қалпына келтіруім мүмкін | 2.5. `git stash` |
| Коммит жасадым; бір коммитке артқа қайтуым керек | 3\. `git checkout <commit>` |
| Кейінгі коммиттер қажет емес екеніне сенімдімін | 4\. `git reset --hard` |
| Деструктивті командамен әлдеқашан өшіріп тастадым | 5\. `git reflog` |

## Қайтаруға ештеңе қалмайтындай жобаны қалай қорғайсыз?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Ең жақсы қайтару — қажет болмайтыны. Қорғаныстың үш ережесі: әр 30 минут сайын ілгерілеуді қарап, жұмыс істейтін кезеңді тексерілген жолдарды ғана анық қосып коммиттеңіз; `.gitignore` ішіне міндетті `.claude/personal/` және `.env*` жолдарын енгізіңіз; ірі тәжірибелерді `git checkout -b experiment-<name>` арқылы жеке тармақта жасаңыз. Бұл коммиттелген файлдар үшін қалпына келтіру аралығын қысқартады; сыртқы жүйелер мен коммиттелмеген жұмысқа әлі де өз қалпына келтіру жоспары қажет.

</div>

**1-ереже. Әр 30 минут сайын коммит жасаңыз.**

«Тапсырма біткенше» күтпеңіз. Жұмыс істейтін кез келген аралық қадамды коммиттеңіз. Коммит хабарламасы кез келген болуы мүмкін; ең бастысы — Claude (не сіз) жұмыс істеп тұрған күйге бір `git checkout` командасымен қайта ала алуы.

```bash
# тапсырма басында
git status                        # барлық индекстелген және индекстелмеген жолдарды қараңыз
git diff                          # өзгерістерді тексеріңіз
# Мысал жолын нақты тексерген файлмен ауыстырыңыз.
git add -- path/to/file.ts
git diff --cached                 # коммитке нақты не кіретінін тексеріңіз
git commit -m "wip: starting User schema migration"

# 30 минуттан кейін (немесе алғашқы жұмыс істейтін итерациядан соң)
git status
git diff
git add -- path/to/file.ts         # қалта үлгісі емес, нақты тексерілген жол
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# тапсырма соңында — мағыналы коммит
git reset --soft HEAD~2           # үш wip коммитті бір коммитке біріктіру
git commit -m "feat(auth): add lastLoginAt field to User table"
```

PostToolUse еске салғышын қоссаңыз, сол тексеру және нақты жолдарды қосу ережесін сақтаңыз. Таймерді тексерусіз автокоммитке айналдырмаңыз: әйтпесе қатысы жоқ түзетулер не бұрын индекстелген файлдар коммитке кіре алады.

**2-ереже. Минималды `.gitignore`.**

Жоба түбірінде мына жолдар болуы керек:

```gitignore
# құпиялар
.env
.env.local
.env.*.local

# жергілікті Claude Code баптаулары (команда репозиторийіне жіберілмейді)
.claude/personal/
.claude/sessions/
.claude/file-history/

# тәуелділіктер мен құрастыру нәтижелері
node_modules/
dist/
.next/
build/
```

Мен жеке тәжірибелерім мен жазбаларыма `.claude/personal/` бумасын қолданамын, ол ортақ репозиторийге кірмеуі керек. `.claude/sessions/` және `.claude/file-history/` — Claude Code-тың жергілікті сақтау бумалары; олар репозиторийге жатпайды, көп орын алады және белгілі бір компьютерге байланған.

**3-ереже. Тәжірибелерді бөлек тармақта жасау.**

Тапсырма ауқымды болса (10+ файлды рефакторинг жасау, жаңа дерекқорға көшу, модульді қайта жазу), оны main тармағында істемеңіз:

```bash
git checkout -b experiment/auth-rewrite
# жұмыс істеп, әр 30 минут сайын коммит жасаңыз
# сәтті болса:
git checkout main
git merge experiment/auth-rewrite
# сәтсіз болса:
git checkout main
git branch -D experiment/auth-rewrite     # тармақты жою
# болды, main тармағы бүтін қалды
```

Бұл қарапайым әдет «Claude жобаны бүлдірді» дегенді «Claude бір тармақты бүлдірді, мен оны жойдым да, қайта бастаймыз» дегенге айналдырады.

**4-ереже. Қауіпті операциялар алдында `git tag` қолданыңыз.**

Дерекқор миграциясы, ірі рефакторинг немесе тәуелділікті жаңарту алдында тег жасаңыз:

```bash
git tag pre-prisma-migration-v2
# жұмыс
# бірдеңе дұрыс болмады:
git reset --hard pre-prisma-migration-v2
# немесе жай ғана қарап шығу:
git checkout pre-prisma-migration-v2
```

Тег — reflog тазартылғаннан кейін де жоғалмайтын коммитке қойылған атаулы сілтеме.

## Келесі қадам: қайтару контекст инженериясына қалай кіреді?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Осы бөлімнің негізгі түйіні">

Негізгі түйін

Қайтару — бөлек дағды емес, Claude Code сеансының контекстін басқарудың бір бөлігі. `/rewind` пәрменін қашан басу, қашан `git commit` жасау және қашан `git stash` қолдану керегін білсеңіз, бір команда емес, тұтас жұмыс процесін басқарасыз. Бұл — **Контекст инженериясының** бөлігі. Онсыз Claude әдеттегі көмекші сияқты әрекет етеді; ал онымен болжамды құралға айналады.

</div>

Қайтарудың осы үш деңгейі бір дағдыға арналған негіз: бұзылғанда күйді қалай қалпына келтіру керегін білу. Бұл дағдының өзі тар ауқымды. Бірақ басқа контекст инженериясы құралдарымен біріктіргенде, ол әлдеқайда пайдалы болады.

Plan Mode кодты бірден жазуға мүмкіндік бермейді — алдымен жоспар, содан кейін растау, соңында орындау келеді. Бұл — алдын ала қайтару: жоспар алдын ала қаралғандықтан, кейін болдырмауға тура келетін нәрсені жазбайсыз. Толығырақ [Claude Code-тағы Plan Mode нұсқаулығынан](https://ailoot.ai/blog/kk/claude-code-plan-mode/) оқыңыз.

[CLAUDE.md](https://ailoot.ai/blog/kk/claude-md-template/) Claude әдепкіде орындайтын ережелерді, соның ішінде жоғарыда айтылған Git Safety Protocol-ды белгілейді. Бұл — деструктивті командалардан алдын ала қорғаныс.

[Екінші ми](https://ailoot.ai/blog/kk/claude-code-second-brain/) Claude-қа сеанстар арасында жоба туралы жад береді: онда қандай код барын, бизнес логикасының қандай екенін және бұрын қандай келісімдер жасалғанын біледі. Жады неғұрлым мол болса, қате әрекет жасау ықтималдығы соғұрлым аз.

[Skills пен субагенттер](https://ailoot.ai/blog/kk/claude-code-skills-library/) — кодыңызға енгізілген әдістемеңіз. Дұрыс git жұмыс процесі Skill ішіне енгізілсе, ешбір субагент растаусыз `git reset --hard` орындамайды.

Осының бәрі бірге **Контекст инженериясын** құрайды. Контексті сұрау кезінде емес, одан бұрын басқарыңыз. Толығырақ [контекст инженериясы деген не](https://ailoot.ai/blog/kk/context-engineering/) мақаласынан оқыңыз.

Қайтару — қорғаныстың соңғы шебі. Plan Mode + CLAUDE.md + Екінші ми + Skills — алғашқы төрт шеп. Олар дұрыс бапталса, қайтару сирек әрі жылдам болады. Бапталмаса, күнделікті әдетке айналады.

<div class="section" role="doc-bibliography" aria-label="Дереккөздер">

### Дереккөздер

- [Anthropic құжаттамасы - Checkpointing](https://code.claude.com/docs/en/checkpointing)
- [Anthropic құжаттамасы - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new)
- [Anthropic құжаттамасы - Permission Modes](https://code.claude.com/docs/en/permission-modes)
- [Git Reference - reflog](https://git-scm.com/docs/git-reflog)

</div>

Қайтару жоспарлау аяқталған жерде басталады.





[Ailoot-қа өтіңіз](https://ailoot.ai/).

## Жиі қойылатын сұрақтар

### WIP бақылау коммитінде git add . қолдану керек пе?

Жоқ. `git status` пен `git diff` орындап, тек қарап шыққан атаулы файлдарды индекске қосыңыз, кейін коммитке дейін `git diff --cached` қараңыз. Мерзімді бақылау коммиті қатысы жоқ не бұрын индекстелген өзгерістерді қосуға рұқсат бермейді.

### /rewind дерекқор миграциясын не қашықтағы API әрекетін қайтара ала ма?

Жоқ. Нұсқаулық checkpoint-ті сеанстағы қолдау көрсетілетін файл түзетулерімен шектейді. Дерекқор, қашықтағы Git және API әсерлеріне бөлек қалпына келтіру қадамдары қажет; қамтылмаған файлдарға Git не сақтық көшірме қолданыңыз.


## Ailoot · Компания және оның жобалар портфелі

Ailoot жинақталған жұмыс тәжірибесіне, кең клиенттік базаға, тұрақты қызметке және KPI көрсеткіштерін үздіксіз бақылауға сүйенеді.

Компания және оның жобалар портфелі: миллиондаған клиент; ай сайынғы сату көлемі миллиардтармен есептеледі.

Ailoot осы тәжірибені клиенттердің өнімдерінде, агенттерінде, қолданбаларында және автоматтандыруларында жасанды интеллект мүмкіндіктеріне API арқылы қол жеткізуді қамтамасыз етуге пайдаланады.
