วิธียกเลิกการเปลี่ยนแปลงใน Claude Code: /rewind และ git

ข้อมูลเชิงปฏิบัติเกี่ยวกับการใช้งาน Ailoot ดูได้ในเอกสารประกอบ.

การยกเลิกใน Claude Code คืออะไร และทำไมสามระดับถึงยังไม่พอ?#

ฉันเปิดใช้ /rewind ในสัปดาห์แรกที่ใช้ Claude Code หลังจากมันทำตรรกะการยืนยันตัวตนของโปรเจกต์ฉันพังภายในสองพรอมป์ต์ ฉันย้อนกลับ ถอนหายใจโล่งอก แล้วทำงานต่อ อีกหนึ่งเดือนต่อมาเกิดเหตุการณ์อีกครั้ง: ฉันกำลังเขียน schema migration, Claude ช่วยทำงาน, ฉัน commit แล้วสลับ branch—จากนั้นก็รู้ว่าลืมขั้นตอนสำคัญไป /rewind ช่วยไม่ได้—เพราะเซสชันเปลี่ยนไปแล้ว git checkout ไปยัง commit ก่อนหน้าช่วยได้ อีกหนึ่งเดือนต่อมา ฉันเผลอบอกเอเจนต์ว่า “ย้อนทุกอย่างกลับไปยัง push ล่าสุด” แล้วมันรัน git reset --hard ทำให้งานสามชั่วโมงพัง git reflog ช่วยฉันไว้—hash ของ commit ที่ถูกทำลายยังอยู่ที่นั่น

เรื่องราวทั้งสามนี้แสดงถึงการป้องกันสามระดับที่ทำงานต่างกัน จับข้อผิดพลาดต่างกัน และจำเป็นต้องมีทั้งหมด คู่มือนี้อธิบายแต่ละระดับพร้อมคำสั่ง ข้อจำกัด และตัวอย่าง รวมถึงวิธีตั้งค่าโปรเจกต์ล่วงหน้าเพื่อไม่ให้ Claude ทำโปรเจกต์พังตั้งแต่ครั้งแรก

การยกเลิก 3 ระดับ—ใช้อะไรและเมื่อไร:

ต่อไปเราจะไล่ดูแต่ละระดับ—ต้องทำอะไรบ้าง จุดที่ต้องระวัง และวิธีตั้งค่าให้ไม่มีอะไรต้องย้อนกลับเพราะไม่มีอะไรพัง

จะเรียกใช้ /rewind อย่างไร: ใช้คำสั่งหรือกด Esc-Esc?#

หลังจากทุกคำตอบ Claude จะสร้าง snapshot ของไฟล์ทั้งหมดที่แก้ไขในเซสชันนั้นโดยอัตโนมัติ snapshot จะเก็บไว้ใน ~/.claude/file-history/{sessionId}/ และเก็บไว้นานสูงสุด 30 วัน snapshot เป็นแบบ incremental—บันทึกเฉพาะความแตกต่างระหว่างสถานะ ไม่ได้บันทึกไฟล์ทั้งไฟล์ โดยค่าเริ่มต้นจะเก็บ snapshot ได้สูงสุด 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:

คำสั่ง /rewind ทำแบบเดียวกัน—เปิดเมนู นอกจากนี้ยังมี alias คือ /checkpoint ซึ่งนำไปยังเมนูเดียวกัน วิธีไหนสะดวกกว่าขึ้นอยู่กับความเคยชิน ฉันใช้ Esc Esc—เร็วกว่าและไม่ต้องยกมือออกจากแป้นพิมพ์

มี 6 โหมดในเมนู Rewind: ควรเลือกโหมดไหนและเมื่อไร?#

เลือกจุดในรายการ แล้วคุณจะเข้าสู่เมนูการทำงาน มีหกรายการ แต่ละรายการทำงานต่างกัน

ตารางโหมดทั้งหมด:

ฟีเจอร์ Summarize up to here ปรากฏใน Claude Code v2.1.139-v2.1.142 ซึ่งเผยแพร่วันที่ 11–15 พฤษภาคม 2026 ในสัปดาห์ที่ 20:

ความแตกต่างระหว่าง Restore กับ Summarize เป็นเรื่องพื้นฐาน Restore จะคืนไปยังสถานะก่อนหน้าและเลิกทำทุกอย่างที่เกิดขึ้นหลังจุดที่เลือก ส่วน Summarize ไม่ได้เลิกทำอะไรเลย แต่เพียงบีบอัดเท่านั้น—ข้อความต้นฉบับยังคงอยู่ใน transcript ของเซสชันเพื่อใช้อ้างอิง แต่จะเหลือเพียงสรุปในบริบทที่ใช้งานอยู่ ใช้ restore เมื่อคุณต้องการให้ “เหมือนไม่เคยเกิดเรื่องนี้ขึ้น” ใช้ summarize เมื่อคุณต้องการ “เก็บไว้ แต่ไม่ให้กินพื้นที่บริบท”

หลังจาก Restore conversation หรือ Summarize from here ข้อความต้นฉบับของพรอมป์ต์ที่เลือกจะกลับมาอยู่ในช่องป้อนข้อมูล คุณแก้ไขและส่งอีกครั้งได้ หลังจาก Summarize up to here ช่องป้อนข้อมูลจะว่าง และคุณจะอยู่ท้ายบทสนทนา

การเปลี่ยนแปลงแบบใดที่ /rewind ไม่ได้ยกเลิก?#

นี่คือข้อจำกัดหลักที่ผู้คนมักเจอ: /rewind แสดงเครื่องหมายถูกสีเขียวและบอกว่า “ย้อนกลับสำเร็จ” แต่โปรเจกต์ยังพังอยู่เพราะ Claude แตะต้องมากกว่าไฟล์ มาดูทั้งสามกรณีกัน

1. คำสั่ง Bash ไม่ถูกติดตาม หาก Claude รัน rm file.txt หรือ mv old.txt new.txt ในเทิร์นใด การเปลี่ยนแปลงเหล่านั้นจะไม่รวมอยู่ใน checkpoint เอกสารของ Anthropic ระบุไว้อย่างชัดเจนว่า:

หมายความว่า หาก Claude ลบ ย้าย หรือคัดลอกไฟล์เองผ่านเครื่องมือ Bash /rewind จะกู้คืนทุกอย่างไม่ได้ git checkout หรือการกู้คืนจากแบ็กอัปอาจช่วยได้ แต่ต้องทำมากกว่าการกดสองปุ่ม

2. การแก้ไขจากภายนอกจะไม่ถูกจับไว้ หากคุณเปิดไฟล์ใน VS Code แล้วแก้ไขด้วยตนเอง หรือมี Claude อีกเซสชันเปลี่ยนไฟล์เดียวกันไปพร้อมกัน เซสชันแรกจะมองไม่เห็นการเปลี่ยนแปลงเหล่านั้น snapshot ของ checkpoint จะถูกสร้างเมื่อ Claude จบเทิร์นในเซสชันปัจจุบัน สิ่งที่เกิดขึ้นระหว่างเทิร์นอยู่นอกเหนือความรับผิดชอบของมัน

3. การดำเนินการนอกไฟล์ไม่ได้รับการครอบคลุมเลย Prisma migration ที่ใช้ npx prisma migrate dev เปลี่ยน schema ของฐานข้อมูล—/rewind จะยกเลิกไม่ได้เพราะฐานข้อมูลอยู่นอกระบบไฟล์ของโปรเจกต์ การ force-push ไปยัง origin/main ก็เช่นกัน: commit ถูกส่งไปยังเซิร์ฟเวอร์ระยะไกล และ checkpoint จะนำมันกลับมาไม่ได้ การเรียก API ระยะไกลที่เรียกเก็บเงินหรือลบระเบียน จะยกเลิกได้ด้วยกลไกของ API เองเท่านั้น

กฎ: หากงานส่งผลต่อสิ่งใดนอกไฟล์โปรเจกต์—database migration, git push หรือ API ระยะไกล—ให้เตรียมกลยุทธ์ rollback แยกต่างหากสำหรับผลกระทบภายนอกแต่ละอย่าง /rewind เป็นเพียงประวัติไฟล์ในเครื่องภายในเซสชันปัจจุบันเท่านั้น

/rewind กับ git ต่างกันอย่างไร และทำไมต้องใช้ทั้งคู่?#

เอกสารของ Anthropic ระบุถึงการใช้สองอย่างควบคู่กันไว้โดยตรง:

ความแตกต่างในตารางเดียว:

การใช้คู่กันนั้นง่ายมาก: ทุกครั้งที่คุณได้สถานะที่ “ใช้งานได้แล้ว และฉันไม่อยากเสียมันไป” ให้ทำ git commit ระหว่าง commit ให้ใช้ /rewind—ทำงานทันที ไม่ต้องเขียนข้อความ commit และไม่ทำให้ประวัติ git รกด้วยสถานะระหว่างทาง เมื่องานเสร็จแล้วให้ commit—ควรเป็น commit ที่มีความหมายและเป็นหน่วยเดียว

ทำไม /rewind เพียงอย่างเดียวจึงไม่ครอบคลุมงานทั้งหมด?#

การยกเลิกเป็นกรณีหนึ่งของ context engineering จัดการบริบทในเซสชัน (เมื่อไรควร commit, เมื่อไรควรกด /rewind, ควรใส่กฎอะไรใน CLAUDE.md) แล้วคุณจะได้ Claude ที่คาดเดาพฤติกรรมได้ ไม่ทำโปรเจกต์พังหรือทำงานหาย

ทำไม git reset --hard จึงอันตรายเมื่อคุณขอให้ Claude “ย้อนกลับ”?#

คำขอให้ “บันทึกสถานะปัจจุบันและย้อนกลับไปยัง push ล่าสุด” อาจนำไปสู่คำสั่งต่อไปนี้:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saved uncommitted changes
git reset --hard 35eb731                                                # destroyed commits d63695e..882e618

คำสั่งแรกถูกต้อง—บันทึกการเปลี่ยนแปลงที่ยังไม่ได้ commit ไว้ใน stash ส่วนคำสั่งที่สองทำลายข้อมูล: มันเขียน branch ใหม่ไปยัง commit 35eb731 และ commit ทั้งหมดระหว่าง commit นี้กับ 882e618 กลายเป็น orphan โดยค่าเริ่มต้น orphan commit จะยังอยู่ใน .git/objects/ จนกว่า git gc จะทำงาน ซึ่งมักเกิดขึ้นโดยอัตโนมัติภายในสองสัปดาห์ แต่หากตอนนั้นคุณไม่รู้ว่าต้องทำอะไร เวลาก็เริ่มทำงานแข่งกับคุณแล้ว

เหตุผลนั้นเรียบง่าย: ในภาษาธรรมชาติ “ย้อนกลับ”, “กลับไป”, “กู้คืน”, “ย้อนคืน” และ “เลิกทำ” หมายถึง “ดูย้อนหลัง” หรือ “กลับไปยังที่ปลอดภัย” ไม่ได้หมายถึง “ทำลายประวัติ” คำสั่ง git reset --hard ทำลายประวัติ—มันเขียน branch ใหม่และนำ commit ออกจากกลุ่มที่เข้าถึงได้ผ่าน HEAD ทางเลือกที่ปลอดภัยคือ git checkout <commit> ซึ่งสร้าง detached HEAD และให้คุณดูสถานะเก่าโดยไม่แตะต้อง branch

ข้อแนะนำเชิงปฏิบัติหลักคือทำ git commit สถานะปัจจุบันไว้ก่อนเริ่มงานสำคัญ โดยเฉพาะก่อน refactor หลายไฟล์ commit เดียวจะเปลี่ยนความผิดพลาดของ Claude ให้กลายเป็นคำสั่ง git checkout . เพียงคำสั่งเดียวโดยไม่ทำงานหาย

git reflog ช่วยคุณหลังการ reset ที่ทำลายข้อมูลได้อย่างไร?#

หลังจาก reset ที่ทำลายข้อมูล ให้รัน git reflog ทันที:

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} คือ commit ที่ “ถูกทำลาย” เหล่านั้น มันไม่ได้หายไปจาก object store ในเครื่องของ git; เพียงแต่เข้าถึงผ่าน branch ไม่ได้แล้ว หากต้องการกู้คืน:

# Create a branch from the last “destroyed” commit
git branch recovered-work 882e618

# Or switch directly
git reset --hard 882e618

หลังจากนั้น branch จะมีประวัติทั้งหมดจนถึงก่อนเกิดภัยพิบัติอีกครั้ง

ข้อจำกัดของ Reflog:

1. ใช้ได้เฉพาะในเครื่อง Reflog เก็บไว้ใน .git/logs/HEAD; ไม่ได้อยู่บน repository ระยะไกล หากคุณ force-push แล้วลบสำเนา repository ในเครื่อง reflog ก็จะหายไปพร้อมกับโฟลเดอร์
2. ค่าเริ่มต้นคือ 90 วัน รายการที่เก่ากว่านั้นอาจถูกลบโดย git gc คุณตั้งค่าได้ด้วย git config gc.reflogExpire 200.days.ago
3. ไม่ครอบคลุมสิ่งที่ไม่เคยอยู่ใน HEAD หาก commit มีอยู่แค่ใน stash แล้ว stash ถูกทำลาย reflog จะแสดงเฉพาะสถานะล่าสุดของ stash ไม่ใช่ประวัติภายในของมัน

กฎสำหรับทีม: อย่ารัน git gc --aggressive ทันทีหลังเกิดภัยพิบัติ ตรวจสอบด้วย reflog และกู้คืนก่อน แล้วค่อยทำอย่างอื่น และอย่าลบโคลน repository ในเครื่องจนกว่าจะแน่ใจว่าสิ่งที่ต้องการถูก push ขึ้นไปหมดแล้ว

จะป้องกันโปรเจกต์จากคำสั่ง git ที่ทำลายข้อมูลผ่าน CLAUDE.md ได้อย่างไร?#

ช่องโหว่คือ Claude ไม่มีบริบทป้องกันมาให้โดยค่าเริ่มต้น มันตีความ “ย้อนกลับ” ว่าหมายถึง git reset --hard เพราะในทางเทคนิคเป็นวิธีที่ถูกต้อง ใส่การป้องกันไว้ใน CLAUDE.md—ไฟล์พรอมป์ต์ระบบของโปรเจกต์

กฎขั้นต่ำ (ใส่ใน CLAUDE.md ของคุณ):

## Git Safety Protocol

- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless I explicitly request these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work.
- When I say "roll back", "go back", "restore", "revert", "undo" - interpret as REVIEW commands: use `git log`, `git diff`, `git checkout <commit>` (creates detached HEAD), or `git stash` (preserves changes).
- ALWAYS ask for confirmation before ANY command that:
  - Changes HEAD position to a different commit on a branch
  - Modifies commit history
  - Could lose uncommitted work
  - Includes flags --hard, --force, --aggressive
- Before any destructive command, output a numbered comparison:
  - SAFE: use `git checkout <commit>` to view temporarily
  - DESTRUCTIVE: use `git reset --hard` to permanently destroy
- Wait for my explicit choice before executing.

กฎเพิ่มเติม สำหรับทีม (เพิ่มใน CLAUDE.md ที่ราก repository):

## Git Workflow Rules

- commit ทุก milestone ที่ทำงานได้ ก่อน WIP commit รัน `git status` กับ `git diff` stage เฉพาะไฟล์ชื่อชัดที่ตรวจแล้วด้วย `git add -- path/to/file` แล้วตรวจ staged diff ก่อน commit ตัวจับเวลาเตือนให้รีวิว ไม่ใช่อนุญาต stage ทั้ง 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.

หลังจากเพิ่มบล็อกเหล่านี้แล้ว ประโยค “ย้อนกลับไปยัง push ล่าสุด” จะนำไปสู่คำตอบแบบนี้:

ฉันเห็นไฟล์ที่ยังไม่ได้ commit 3 ไฟล์ และมี 4 commit ที่ใหม่กว่า push ล่าสุด มีสองทางเลือก:

1. ปลอดภัย: สร้าง branch view-last-push ผ่าน git checkout <last-push-hash>—ฉันจะเก็บงานทั้งหมดไว้ แต่แสดงสถานะของ push นั้นชั่วคราว
2. ทำลายข้อมูล: git reset --hard <last-push-hash>—ฉันจะทำลาย 4 commit และการเปลี่ยนแปลงที่ยังไม่ได้ commit อย่างถาวร กู้คืนได้ผ่าน git reflog ภายใน 90 วันเท่านั้น คุณจะเลือกแบบไหน?

ใช้เวลาคุยกันครึ่งนาที แทนที่จะเสียงานไปสี่ชั่วโมง

5 วิธีในการยกเลิกใน Claude Code มีอะไรบ้าง และจะเลือกวิธีที่เหมาะสมอย่างไร?#

สถานการณ์ “Claude ทำพัง ฉันต้องกู้คืนอย่างเร่งด่วน” ให้ไล่ลงมาตามขั้นบันไดนี้ เริ่มที่ระดับ 1 เสมอ

ระดับ 1. /rewind—ยกเลิกทันทีภายในเซสชัน

กด Esc Esc หรือพิมพ์ /rewind เลือกจุดก่อนเกิดปัญหา เลือกโหมด (โดยทั่วไปคือ Restore code and conversation) อีกหนึ่งวินาทีต่อมา คุณก็กลับไปยังอดีตและเริ่มใหม่ได้ ครอบคลุม 80% ของกรณี “Claude ทำผิดทาง”

ระดับ 2. git checkout .—ยกเลิกการเปลี่ยนแปลงทั้งหมดที่ยังไม่ได้ commit

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

มีประโยชน์เมื่อ /rewind ไม่ได้ผล (เช่น Claude แตะไฟล์ผ่าน Bash) หรือเมื่อต้องการยกเลิกการเปลี่ยนแปลงนอกประวัติของเซสชัน การเปลี่ยนแปลงทั้งหมดที่ยังไม่ได้ commit จะหายไปอย่างถาวร หากคุณอาจเสียใจ ให้รัน git stash ก่อน (ดูระดับ 2.5)

ระดับ 2.5. git stash—เก็บการเปลี่ยนแปลงไว้ก่อน

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

เป็นทางสายกลางที่ดีระหว่าง “เสียไปตลอดกาล” กับ “ปล่อยไว้อย่างนั้น” stash จะอยู่ในเครื่องจนกว่าจะลบอย่างชัดเจน

ระดับ 3. git checkout <commit>—กลับไปยัง commit เก่าโดยไม่เสียประวัติ

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

นี่คือ “การย้อนกลับชั่วคราว” อย่างปลอดภัย Detached HEAD ไม่เปลี่ยน branch; งานปัจจุบันของคุณใน main (หรือ branch ที่คุณใช้อยู่) ยังคงอยู่ครบ หากต้องการทำงานกับสถานะนี้ ให้สร้าง branch

ระดับ 4. git reset --hard <commit>—เลื่อน branch กลับไปยังจุดหนึ่ง

⚠️ ทำลายข้อมูล commit ที่อยู่ถัดจาก hash ที่ระบุจะกลายเป็น orphan

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

ใช้เฉพาะเมื่อแน่ใจว่าไม่ต้องการ commit ที่อยู่ถัดไป และตรวจสอบ git reflog ก่อน reset เสมอ เพื่อให้รู้ว่าจะกลับไปที่ใดหากเปลี่ยนใจ

ระดับ 5. git reflog + การกู้คืน—สถานการณ์หายนะ

มีใครบางคน (Claude, คุณ หรือเพื่อนร่วมงาน) รัน git reset --hard หรือ force-push และลบงานไปแล้ว ต้องทำอย่างไร?

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

หาก reflog ถูกล้างไปแล้ว (โดยค่าเริ่มต้นหลัง 90 วัน) วิธีสุดท้ายคือ git fsck --lost-found ซึ่งจะแสดง commit ที่ไม่มีจุดอ้างอิงอยู่ใน .git/objects/ นี่แทบจะเป็นงานโบราณคดี แต่บางครั้งก็ได้ผล

กฎการเลือกระดับ:

จะป้องกันโปรเจกต์อย่างไรเพื่อไม่ให้มีอะไรต้องยกเลิก?#

กฎ 1. Commit ทุก 30 นาที

อย่ารอจนกว่า “งานจะเสร็จ” commit ทุกขั้นกลางที่ใช้งานได้ ข้อความ commit จะเขียนอะไรก็ได้ สิ่งสำคัญคือ Claude (หรือคุณ) สามารถกลับไปยังสถานะที่ใช้งานได้ด้วยคำสั่ง git checkout เพียงคำสั่งเดียว

# at the beginning of a task
git status                        # inspect all staged and unstaged paths
git diff                          # review the changes
# Replace this example path with the actual file you reviewed.
git add -- path/to/file.ts
git diff --cached                 # verify exactly what will be committed
git commit -m "wip: starting User schema migration"

# after 30 minutes (or after the first working iteration)
git status
git diff
git add -- path/to/file.ts         # actual reviewed path, not a directory wildcard
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

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

หากเพิ่ม PostToolUse เพื่อเตือน ให้คงกฎรีวิวและ stage เฉพาะ path ชัด ห้ามเปลี่ยนตัวจับเวลาเป็น auto-commit ที่ไม่ตรวจ เพราะการแก้ไม่เกี่ยวข้องหรือไฟล์ที่ staged อยู่ก่อนอาจปนเข้า commit

กฎ 2. .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/

ฉันเก็บโฟลเดอร์ .claude/personal/ ไว้สำหรับการทดลองและบันทึกส่วนตัว ซึ่งต้องไม่รวมไว้ใน repository ที่แชร์กัน ส่วนโฟลเดอร์ .claude/sessions/ และ .claude/file-history/ เป็นที่เก็บข้อมูลในเครื่องของ Claude Code; ไม่ควรอยู่ใน repository ใช้พื้นที่มาก และผูกกับเครื่องใดเครื่องหนึ่ง

กฎ 3. ทดลองใน branch แยก

หากงานมีขนาดใหญ่ (refactor 10+ ไฟล์, ย้ายไปใช้ฐานข้อมูลใหม่, เขียนโมดูลใหม่) อย่าทำใน branch หลัก:

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

นิสัยง่าย ๆ นี้เปลี่ยนสถานการณ์ “Claude ทำโปรเจกต์พัง” ให้กลายเป็น “Claude ทำ branch เดียวพัง ฉันลบมัน แล้วเริ่มใหม่”

กฎ 4. ใช้ git tag ก่อนทำงานที่เสี่ยง

สร้าง tag ก่อน database migration, refactor ครั้งใหญ่ หรืออัปเดต dependency:

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 คือ pointer ที่มีชื่อไปยัง commit ซึ่งจะไม่หายไปแม้จะล้าง reflog แล้ว

ต่อไป: การยกเลิกเกี่ยวข้องกับ context engineering อย่างไร?#

การยกเลิกสามระดับนี้เป็นพื้นฐานของทักษะหนึ่งอย่าง: รู้วิธีกู้คืนสถานะเมื่อเกิดปัญหา ทักษะนี้เพียงอย่างเดียวค่อนข้างจำกัด แต่เมื่อรวมกับเครื่องมือ context engineering อื่น ๆ ก็กลายเป็นสิ่งที่มากกว่านั้น

Plan Mode ไม่อนุญาตให้เขียนโค้ดทันที—ต้องเริ่มจากแผน ตามด้วยการยืนยัน แล้วจึงลงมือ นี่คือการป้องกันการต้องยกเลิก: คุณไม่เขียนสิ่งที่ต้องมายกเลิกภายหลัง เพราะได้ตรวจทานแผนล่วงหน้าแล้ว อ่านเพิ่มเติมได้ในคู่มือ Plan Mode ใน Claude Code

CLAUDE.md กำหนดกฎที่ Claude เคารพโดยค่าเริ่มต้น รวมถึง Git Safety Protocol ที่กล่าวถึงข้างต้น นี่คือการป้องกันคำสั่งที่ทำลายข้อมูลล่วงหน้า

Second Brain มอบความทรงจำเกี่ยวกับโปรเจกต์ให้ Claude ระหว่างเซสชัน—มันรู้ว่าคุณมีโค้ดอะไร ตรรกะทางธุรกิจเป็นอย่างไร และก่อนหน้านี้ตกลงอะไรกันไว้ ยิ่งมีความทรงจำมาก โอกาสที่มันจะทำผิดก็ยิ่งน้อยลง

Skills และ subagents คือระเบียบวิธีของคุณที่เขียนเป็นโค้ด หากเวิร์กโฟลว์ git ที่ถูกต้องฝังอยู่ใน Skill ก็จะไม่มี subagent ตัวใดรัน git reset --hard โดยไม่ขอการยืนยัน

ทั้งหมดนี้รวมกันคือ Context Engineering จัดการบริบทก่อนพรอมป์ต์ ไม่ใช่ระหว่างทำงาน อ่านเพิ่มเติมได้ในบทความ context engineering คืออะไร

การยกเลิกคือแนวป้องกันด่านสุดท้าย ส่วน Plan Mode + CLAUDE.md + Second Brain + Skills คือสี่ด่านแรก เมื่อกำหนดค่าไว้ครบ การยกเลิกก็เกิดขึ้นไม่บ่อยและทำได้อย่างรวดเร็ว หากไม่มี ก็กลายเป็นพิธีกรรมประจำวัน

การยกเลิกเริ่มต้นตรงที่การวางแผนสิ้นสุดลง

ไปที่ Ailoot.