# วิธียกเลิกการเปลี่ยนแปลงใน Claude Code: /rewind และ git > โหมดการย้อนกลับ ข้อจำกัดของ checkpointing, git checkout, stash, reflog และการป้องกันคำสั่งที่ทำลายข้อมูล 5 วิธีในการกู้คืนสถานะ Source: https://ailoot.ai/blog/th/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/th/claude-code-undo-changes/ Language: th Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-064172cc389109dd829c81322fcc1ce688f773c16d1d9707f23980b3c34ba3b8 [ข้อมูลเชิงปฏิบัติเกี่ยวกับการใช้งาน Ailoot ดูได้ในเอกสารประกอบ](https://ailoot.ai/docs/). ## การยกเลิกใน Claude Code คืออะไร และทำไมสามระดับถึงยังไม่พอ?
ประเด็นสำคัญ การยกเลิกใน Claude Code มีสามระดับ ได้แก่ คำสั่งในตัว `/rewind` (กู้คืนทันทีภายในเซสชัน), `git checkout` (คืนสถานะไปยัง commit ล่าสุด) และ `git reflog` (ตาข่ายนิรภัยในกรณีฉุกเฉิน หากมีคนรัน `git reset --hard`) แต่ละระดับรองรับข้อผิดพลาดคนละประเภท และไม่ครอบคลุมเกินขอบเขตของตัวเอง หากรู้จักเพียง `/rewind` ก็จะตั้งตัวไม่ทันเมื่อเจอความผิดพลาดร้ายแรงครั้งแรก
ฉันเปิดใช้ `/rewind` ในสัปดาห์แรกที่ใช้ Claude Code หลังจากมันทำตรรกะการยืนยันตัวตนของโปรเจกต์ฉันพังภายในสองพรอมป์ต์ ฉันย้อนกลับ ถอนหายใจโล่งอก แล้วทำงานต่อ อีกหนึ่งเดือนต่อมาเกิดเหตุการณ์อีกครั้ง: ฉันกำลังเขียน schema migration, Claude ช่วยทำงาน, ฉัน commit แล้วสลับ branch—จากนั้นก็รู้ว่าลืมขั้นตอนสำคัญไป `/rewind` ช่วยไม่ได้—เพราะเซสชันเปลี่ยนไปแล้ว `git checkout` ไปยัง commit ก่อนหน้าช่วยได้ อีกหนึ่งเดือนต่อมา ฉันเผลอบอกเอเจนต์ว่า “ย้อนทุกอย่างกลับไปยัง push ล่าสุด” แล้วมันรัน `git reset --hard` ทำให้งานสามชั่วโมงพัง `git reflog` ช่วยฉันไว้—hash ของ commit ที่ถูกทำลายยังอยู่ที่นั่น เรื่องราวทั้งสามนี้แสดงถึงการป้องกันสามระดับที่ทำงานต่างกัน จับข้อผิดพลาดต่างกัน และจำเป็นต้องมีทั้งหมด คู่มือนี้อธิบายแต่ละระดับพร้อมคำสั่ง ข้อจำกัด และตัวอย่าง รวมถึงวิธีตั้งค่าโปรเจกต์ล่วงหน้าเพื่อไม่ให้ Claude ทำโปรเจกต์พังตั้งแต่ครั้งแรก **การยกเลิก 3 ระดับ—ใช้อะไรและเมื่อไร:** | ระดับ | คำสั่ง | ครอบคลุม | ไม่ครอบคลุม | |----|----|----|----| | 1\. ภายในเซสชัน | `/rewind` หรือ `Esc Esc` | ไฟล์ที่ Claude แก้ไขผ่านเครื่องมือของตัวเอง; ประวัติการสนทนา | คำสั่ง Bash, โปรแกรมแก้ไขภายนอก, database migration | | 2\. ก่อน commit | `git checkout .` หรือ `git stash` | การเปลี่ยนแปลงไฟล์ทั้งหมดที่ยังไม่ได้ commit | commit ที่ commit ไปแล้ว | | 3\. ภัยพิบัติ | `git reflog` + `git reset --hard ` | commit ที่ถูกทำลายด้วย `reset --hard` หรือ force-push | คำสั่ง Bash ที่ทำลายข้อมูล (rm, database migration) | ต่อไปเราจะไล่ดูแต่ละระดับ—ต้องทำอะไรบ้าง จุดที่ต้องระวัง และวิธีตั้งค่าให้ไม่มีอะไรต้องย้อนกลับเพราะไม่มีอะไรพัง ## จะเรียกใช้ /rewind อย่างไร: ใช้คำสั่งหรือกด Esc-Esc?
ประเด็นสำคัญ มีสองวิธีในการเปิดเมนู Rewind ใน Claude Code วิธีแรกคือพิมพ์ `/rewind` ในช่องป้อนข้อมูล วิธีที่สองคือกด `Esc` สองครั้งเมื่อช่องป้อนข้อมูลว่าง หากมีข้อความอยู่ในช่อง การกด Esc สองครั้งครั้งแรกจะล้างข้อความและบันทึกเนื้อหาไว้ในประวัติอินพุต การกดสองครั้งอีกครั้งจะเปิดเมนู คำสั่ง `/rewind` มี alias เป็น `/checkpoint`
หลังจากทุกคำตอบ 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:

หากมีข้อความอยู่ในช่องพรอมป์ต์ การกด Esc สองครั้งจะล้างข้อความก่อนแทนที่จะเปิดเมนู ข้อความที่ถูกล้างจะถูกบันทึกไว้ในประวัติอินพุต คุณจึงเรียกคืนได้ด้วยปุ่มลูกศรขึ้นหลังจากเมนูย้อนกลับ

— เอกสาร Anthropic, https://code.claude.com/docs/en/checkpointing
คำสั่ง `/rewind` ทำแบบเดียวกัน—เปิดเมนู นอกจากนี้ยังมี alias คือ `/checkpoint` ซึ่งนำไปยังเมนูเดียวกัน วิธีไหนสะดวกกว่าขึ้นอยู่กับความเคยชิน ฉันใช้ `Esc Esc`—เร็วกว่าและไม่ต้องยกมือออกจากแป้นพิมพ์ ## มี 6 โหมดในเมนู Rewind: ควรเลือกโหมดไหนและเมื่อไร?
ประเด็นสำคัญ หลังจากเลือกจุดย้อนกลับในเมนู Rewind แล้ว จะมีเมนูที่สองปรากฏขึ้นพร้อม 6 โหมด สามโหมดคืนสถานะ (`Restore code and conversation`, `Restore conversation`, `Restore code`), สองโหมดบีบอัดประวัติ (`Summarize from here`, `Summarize up to here`) และหนึ่งโหมดยกเลิกการทำงาน (`Never mind`) สถานการณ์ที่พบบ่อยที่สุด—“ย้อนกลับทั้งโค้ดและบทสนทนา”—คือทางเลือกแรก
เลือกจุดในรายการ แล้วคุณจะเข้าสู่เมนูการทำงาน มีหกรายการ แต่ละรายการทำงานต่างกัน **ตารางโหมดทั้งหมด:** | โหมด | ทำอะไร | ควรเลือกเมื่อไร | |----|----|----| | `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 ซึ่งเผยแพร่วันที่ 11–15 พฤษภาคม 2026 ในสัปดาห์ที่ 20:

คุณสามารถบีบอัดบริบทช่วงแรกผ่านเมนู Rewind โดยใช้ 'Summarize up to here'

— มีอะไรใหม่ใน Anthropic, https://code.claude.com/docs/en/whats-new
ความแตกต่างระหว่าง `Restore` กับ `Summarize` เป็นเรื่องพื้นฐาน Restore จะคืนไปยังสถานะก่อนหน้าและเลิกทำทุกอย่างที่เกิดขึ้นหลังจุดที่เลือก ส่วน Summarize ไม่ได้เลิกทำอะไรเลย แต่เพียงบีบอัดเท่านั้น—ข้อความต้นฉบับยังคงอยู่ใน transcript ของเซสชันเพื่อใช้อ้างอิง แต่จะเหลือเพียงสรุปในบริบทที่ใช้งานอยู่ ใช้ restore เมื่อคุณต้องการให้ “เหมือนไม่เคยเกิดเรื่องนี้ขึ้น” ใช้ summarize เมื่อคุณต้องการ “เก็บไว้ แต่ไม่ให้กินพื้นที่บริบท” หลังจาก `Restore conversation` หรือ `Summarize from here` ข้อความต้นฉบับของพรอมป์ต์ที่เลือกจะกลับมาอยู่ในช่องป้อนข้อมูล คุณแก้ไขและส่งอีกครั้งได้ หลังจาก `Summarize up to here` ช่องป้อนข้อมูลจะว่าง และคุณจะอยู่ท้ายบทสนทนา ## การเปลี่ยนแปลงแบบใดที่ /rewind ไม่ได้ยกเลิก?
ประเด็นสำคัญ `/rewind` ติดตามเฉพาะการเปลี่ยนแปลงที่ Claude ทำผ่านเครื่องมือแก้ไขไฟล์ของตัวเองเท่านั้น มันมองไม่เห็นหรือกู้คืนสิ่งอื่นใดไม่ได้ มีการเปลี่ยนแปลงที่มองไม่เห็นสามประเภท ได้แก่ คำสั่ง Bash (rm, mv, cp), การแก้ไขจากภายนอก (การแก้ไขด้วยตนเองใน IDE และการเปลี่ยนแปลงจากเซสชันอื่น) และการดำเนินการนอกไฟล์ (database migration, git push, การเรียก API ระยะไกล)
นี่คือข้อจำกัดหลักที่ผู้คนมักเจอ: `/rewind` แสดงเครื่องหมายถูกสีเขียวและบอกว่า “ย้อนกลับสำเร็จ” แต่โปรเจกต์ยังพังอยู่เพราะ Claude แตะต้องมากกว่าไฟล์ มาดูทั้งสามกรณีกัน **1. คำสั่ง Bash ไม่ถูกติดตาม** หาก Claude รัน `rm file.txt` หรือ `mv old.txt new.txt` ในเทิร์นใด การเปลี่ยนแปลงเหล่านั้นจะไม่รวมอยู่ใน checkpoint เอกสารของ Anthropic ระบุไว้อย่างชัดเจนว่า:

Checkpointing ไม่ได้ติดตามไฟล์ที่เปลี่ยนแปลงผ่านคำสั่ง Bash ตัวอย่างเช่น หาก Claude Code รัน rm file.txt, mv old.txt new.txt, cp source.txt dest.txt จะไม่สามารถยกเลิกการเปลี่ยนแปลงไฟล์เหล่านี้ผ่านการย้อนกลับได้

— เอกสาร Anthropic, https://code.claude.com/docs/en/checkpointing
หมายความว่า หาก 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 ต่างกันอย่างไร และทำไมต้องใช้ทั้งคู่?
ประเด็นสำคัญ `/rewind` คือการย้อนกลับในเครื่องภายใน Claude Code เซสชันเดียว โดยเก็บ snapshot แบบ incremental ได้นานสูงสุด 30 วัน และสูงสุด 100 รายการต่อเซสชัน ส่วน git คือประวัติโปรเจกระยะยาวที่แชร์กันในทีม มี branch, merge conflict และ repository ระยะไกล ทั้งสองอย่างใช้แทนกันไม่ได้ แนวทางที่ดีที่สุดคือทำ `git commit` ในทุกหมุดหมายเชิงตรรกะ แล้วใช้ `/rewind` ระหว่าง commit
เอกสารของ Anthropic ระบุถึงการใช้สองอย่างควบคู่กันไว้โดยตรง:

Checkpoint ออกแบบมาเพื่อการกู้คืนอย่างรวดเร็วในระดับเซสชัน สำหรับ commit, branch และประวัติระยะยาว ให้ใช้ระบบควบคุมเวอร์ชันต่อไป (ตัวอย่างเช่น Git) Checkpoint ช่วยเสริม แต่ไม่ทดแทนการควบคุมเวอร์ชันตามปกติ ลองนึกถึง checkpoint ว่าเป็น 'การยกเลิกในเครื่อง' และ Git ว่าเป็น 'ประวัติถาวร'

— เอกสาร Anthropic, https://code.claude.com/docs/en/checkpointing
ความแตกต่างในตารางเดียว: | พารามิเตอร์ | /rewind | git | |----|----|----| | ความละเอียด | ทุกเทิร์นในการสนทนา | ทุก commit | | ที่เก็บ | สูงสุด 30 วัน, สูงสุด 100 รายการต่อเซสชัน, เก็บในเครื่องที่ `~/.claude/file-history/` | ถาวรใน `.git/` ของ repository และบนเซิร์ฟเวอร์ระยะไกล | | ติดตามอะไร | การแก้ไขของ Claude ผ่านเครื่องมือของตัวเอง | การเปลี่ยนแปลงทั้งหมดที่ commit แล้ว | | ไม่ได้ติดตามอะไร | Bash, การแก้ไขจากภายนอก, migration, push | การเปลี่ยนแปลงที่ยังไม่ได้ commit | | คำสั่ง | คำสั่งภายใน Claude | ระบบควบคุมเวอร์ชันภายนอก | | ย้อนบทสนทนา | ได้ | ไม่ได้ | | ใช้ข้ามเซสชัน | ใช้ได้เฉพาะเซสชันเดิม | ใช้ได้ทุกที่ | การใช้คู่กันนั้นง่ายมาก: ทุกครั้งที่คุณได้สถานะที่ “ใช้งานได้แล้ว และฉันไม่อยากเสียมันไป” ให้ทำ `git commit` ระหว่าง commit ให้ใช้ `/rewind`—ทำงานทันที ไม่ต้องเขียนข้อความ commit และไม่ทำให้ประวัติ git รกด้วยสถานะระหว่างทาง เมื่องานเสร็จแล้วให้ commit—ควรเป็น commit ที่มีความหมายและเป็นหน่วยเดียว ## ทำไม /rewind เพียงอย่างเดียวจึงไม่ครอบคลุมงานทั้งหมด? การยกเลิกเป็นกรณีหนึ่งของ **context engineering** จัดการบริบทในเซสชัน (เมื่อไรควร commit, เมื่อไรควรกด `/rewind`, ควรใส่กฎอะไรใน `CLAUDE.md`) แล้วคุณจะได้ Claude ที่คาดเดาพฤติกรรมได้ ไม่ทำโปรเจกต์พังหรือทำงานหาย ## ทำไม `git reset --hard` จึงอันตรายเมื่อคุณขอให้ Claude “ย้อนกลับ”?
ประเด็นสำคัญ ในภาษาธรรมชาติ “ย้อนกลับ” หมายถึง “ดูประวัติ” ไม่ใช่ “ทำลายประวัติ”; Claude ควรเสนอ `git checkout` เป็นค่าเริ่มต้น ไม่ใช่ `reset --hard`; ตั้งค่าการป้องกันไว้ใน CLAUDE.md
คำขอให้ “บันทึกสถานะปัจจุบันและย้อนกลับไปยัง push ล่าสุด” อาจนำไปสู่คำสั่งต่อไปนี้: ```bash 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 ` ซึ่งสร้าง detached HEAD และให้คุณดูสถานะเก่าโดยไม่แตะต้อง branch ข้อแนะนำเชิงปฏิบัติหลักคือทำ `git commit` สถานะปัจจุบันไว้ก่อนเริ่มงานสำคัญ โดยเฉพาะก่อน refactor หลายไฟล์ commit เดียวจะเปลี่ยนความผิดพลาดของ Claude ให้กลายเป็นคำสั่ง `git checkout .` เพียงคำสั่งเดียวโดยไม่ทำงานหาย ## git reflog ช่วยคุณหลังการ reset ที่ทำลายข้อมูลได้อย่างไร?
ประเด็นสำคัญ `git reflog` แสดงประวัติในเครื่องของการเคลื่อนไหว HEAD ทั้งหมดใน repository—รวมถึง commit ที่ถูกลบด้วย `git reset --hard` หรือ force-push โดยค่าเริ่มต้นการเคลื่อนไหวแต่ละครั้งจะถูกเก็บไว้ 90 วัน หาก Claude (หรือคุณหรือคนอื่น) ทำลาย commit ด้วยคำสั่งที่ทำลายข้อมูล `git reflog` จะแสดง hash ของ commit เหล่านั้น และคุณสามารถกู้คืน branch ด้วย `git reset --hard `
หลังจาก 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}` คือ commit ที่ “ถูกทำลาย” เหล่านั้น มันไม่ได้หายไปจาก object store ในเครื่องของ git; เพียงแต่เข้าถึงผ่าน branch ไม่ได้แล้ว หากต้องการกู้คืน: ```bash # 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.md` ของโปรเจกต์ เพื่อกำหนดว่า Claude รันคำสั่ง git ใดได้เอง คำสั่งใดต้องได้รับการยืนยันอย่างชัดเจน และคำสั่งใดห้ามใช้หากผู้ใช้ไม่ได้ระบุวลีที่ตรงตามกำหนด Claude ถือว่า CLAUDE.md เป็นพรอมป์ต์ระบบของโปรเจกต์และปฏิบัติตามกฎเหล่านี้โดยค่าเริ่มต้น วิธีนี้เปลี่ยนพรอมป์ต์ “อันตราย” หนึ่งคำให้กลายเป็นคำสั่งที่ปลอดภัยสองคำ
ช่องโหว่คือ Claude ไม่มีบริบทป้องกันมาให้โดยค่าเริ่มต้น มันตีความ “ย้อนกลับ” ว่าหมายถึง `git reset --hard` เพราะในทางเทคนิคเป็นวิธีที่ถูกต้อง ใส่การป้องกันไว้ใน `CLAUDE.md`—ไฟล์พรอมป์ต์ระบบของโปรเจกต์ **กฎขั้นต่ำ** (ใส่ใน `CLAUDE.md` ของคุณ): ```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. ``` **กฎเพิ่มเติม** สำหรับทีม (เพิ่มใน `CLAUDE.md` ที่ราก repository): ```markdown ## 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 `—ฉันจะเก็บงานทั้งหมดไว้ แต่แสดงสถานะของ push นั้นชั่วคราว > 2. **ทำลายข้อมูล:** `git reset --hard `—ฉันจะทำลาย 4 commit และการเปลี่ยนแปลงที่ยังไม่ได้ commit อย่างถาวร กู้คืนได้ผ่าน `git reflog` ภายใน 90 วันเท่านั้น คุณจะเลือกแบบไหน? ใช้เวลาคุยกันครึ่งนาที แทนที่จะเสียงานไปสี่ชั่วโมง ## 5 วิธีในการยกเลิกใน Claude Code มีอะไรบ้าง และจะเลือกวิธีที่เหมาะสมอย่างไร?
ประเด็นสำคัญ หากมีสิ่งผิดพลาด ระดับความฉุกเฉินมี 5 ระดับ: `/rewind` (ภายในเซสชัน), `git checkout .` (การเปลี่ยนแปลงที่ยังไม่ได้ commit), `git checkout ` (กลับไปยัง commit เก่าโดยไม่เสียประวัติ), `git reset --hard ` (เลื่อน branch กลับและเสีย commit ที่อยู่ถัดจากจุดนั้น), `git reflog` + การกู้คืน (ภัยพิบัติ ทุกอย่างหายไป) แต่ละระดับหนักและเสี่ยงกว่าระดับก่อนหน้า
สถานการณ์ “Claude ทำพัง ฉันต้องกู้คืนอย่างเร่งด่วน” ให้ไล่ลงมาตามขั้นบันไดนี้ เริ่มที่ระดับ 1 เสมอ **ระดับ 1. `/rewind`—ยกเลิกทันทีภายในเซสชัน** กด `Esc Esc` หรือพิมพ์ `/rewind` เลือกจุดก่อนเกิดปัญหา เลือกโหมด (โดยทั่วไปคือ `Restore code and conversation`) อีกหนึ่งวินาทีต่อมา คุณก็กลับไปยังอดีตและเริ่มใหม่ได้ ครอบคลุม 80% ของกรณี “Claude ทำผิดทาง” **ระดับ 2. `git checkout .`—ยกเลิกการเปลี่ยนแปลงทั้งหมดที่ยังไม่ได้ 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 ``` มีประโยชน์เมื่อ `/rewind` ไม่ได้ผล (เช่น Claude แตะไฟล์ผ่าน Bash) หรือเมื่อต้องการยกเลิกการเปลี่ยนแปลงนอกประวัติของเซสชัน การเปลี่ยนแปลงทั้งหมดที่ยังไม่ได้ commit จะหายไปอย่างถาวร หากคุณอาจเสียใจ ให้รัน `git stash` ก่อน (ดูระดับ 2.5) **ระดับ 2.5. `git stash`—เก็บการเปลี่ยนแปลงไว้ก่อน** ```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 ``` เป็นทางสายกลางที่ดีระหว่าง “เสียไปตลอดกาล” กับ “ปล่อยไว้อย่างนั้น” stash จะอยู่ในเครื่องจนกว่าจะลบอย่างชัดเจน **ระดับ 3. `git checkout `—กลับไปยัง commit เก่าโดยไม่เสียประวัติ** ```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 ``` นี่คือ “การย้อนกลับชั่วคราว” อย่างปลอดภัย Detached HEAD ไม่เปลี่ยน branch; งานปัจจุบันของคุณใน `main` (หรือ branch ที่คุณใช้อยู่) ยังคงอยู่ครบ หากต้องการทำงานกับสถานะนี้ ให้สร้าง branch **ระดับ 4. `git reset --hard `—เลื่อน branch กลับไปยังจุดหนึ่ง** ⚠️ ทำลายข้อมูล commit ที่อยู่ถัดจาก hash ที่ระบุจะกลายเป็น orphan ```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 ``` ใช้เฉพาะเมื่อแน่ใจว่าไม่ต้องการ commit ที่อยู่ถัดไป และตรวจสอบ `git reflog` ก่อน reset เสมอ เพื่อให้รู้ว่าจะกลับไปที่ใดหากเปลี่ยนใจ **ระดับ 5. `git reflog` + การกู้คืน—สถานการณ์หายนะ** มีใครบางคน (Claude, คุณ หรือเพื่อนร่วมงาน) รัน `git reset --hard` หรือ force-push และลบงานไปแล้ว ต้องทำอย่างไร? ```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 ``` หาก reflog ถูกล้างไปแล้ว (โดยค่าเริ่มต้นหลัง 90 วัน) วิธีสุดท้ายคือ `git fsck --lost-found` ซึ่งจะแสดง commit ที่ไม่มีจุดอ้างอิงอยู่ใน `.git/objects/` นี่แทบจะเป็นงานโบราณคดี แต่บางครั้งก็ได้ผล **กฎการเลือกระดับ:** | เกิดอะไรขึ้น | ระดับ | |-----------------------------------------------|-----------------------------| | Claude เขียนไฟล์ 3 ไฟล์ใหม่ในทางที่ผิด | 1\. `/rewind` | | ฉันลองแล้ว ไม่ชอบ และเซสชันช่วยอะไรไม่ได้ | 2\. `git checkout .` | | ฉันทำพังเอง เสียดายถ้าต้องเสียไป แต่อาจกู้คืน | 2.5. `git stash` | | ฉัน commit แล้ว; ต้องย้อนกลับไปหนึ่ง commit | 3\. `git checkout ` | | ฉันแน่ใจว่าไม่ต้องการ commit ที่อยู่ถัดไป | 4\. `git reset --hard` | | ลบไปแล้วด้วยคำสั่งที่ทำลายข้อมูล | 5\. `git reflog` | ## จะป้องกันโปรเจกต์อย่างไรเพื่อไม่ให้มีอะไรต้องยกเลิก?
ประเด็นสำคัญ การยกเลิกที่ดีที่สุดคือแบบที่ไม่ต้องใช้ กฎป้องกันสามข้อ: ตรวจความคืบหน้าทุก 30 นาทีและ commit milestone ที่ทำงานได้โดย stage เฉพาะ path ที่รีวิวแล้วอย่างชัดเจน; ใส่บรรทัด `.claude/personal/` และ `.env*` ที่จำเป็นลงใน `.gitignore`; ทดลองงานใหญ่ใน branch แยกด้วย `git checkout -b experiment-` วิธีนี้ลดช่องว่างกู้คืนสำหรับไฟล์ที่ commit แล้ว ส่วนระบบภายนอกและงานยังไม่ commit ต้องมีแผนกู้ของตน
**กฎ 1. Commit ทุก 30 นาที** อย่ารอจนกว่า “งานจะเสร็จ” commit ทุกขั้นกลางที่ใช้งานได้ ข้อความ commit จะเขียนอะไรก็ได้ สิ่งสำคัญคือ Claude (หรือคุณ) สามารถกลับไปยังสถานะที่ใช้งานได้ด้วยคำสั่ง `git checkout` เพียงคำสั่งเดียว ```bash # 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` ขั้นต่ำ** บรรทัดเหล่านี้จำเป็นในรากโปรเจกต์: ```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 หลัก: ```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 ``` นิสัยง่าย ๆ นี้เปลี่ยนสถานการณ์ “Claude ทำโปรเจกต์พัง” ให้กลายเป็น “Claude ทำ branch เดียวพัง ฉันลบมัน แล้วเริ่มใหม่” **กฎ 4. ใช้ `git tag` ก่อนทำงานที่เสี่ยง** สร้าง tag ก่อน database migration, refactor ครั้งใหญ่ หรืออัปเดต dependency: ```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 คือ pointer ที่มีชื่อไปยัง commit ซึ่งจะไม่หายไปแม้จะล้าง reflog แล้ว ## ต่อไป: การยกเลิกเกี่ยวข้องกับ context engineering อย่างไร?
ประเด็นสำคัญ การยกเลิกไม่ใช่ทักษะแยกต่างหาก แต่เป็นส่วนหนึ่งของการจัดการบริบทเซสชัน Claude Code เมื่อรู้ว่าควรกด `/rewind` เมื่อไร ควรทำ `git commit` เมื่อไร และควรใช้ `git stash` เมื่อไร คุณกำลังจัดการเวิร์กโฟลว์ทั้งหมด ไม่ใช่แค่คำสั่งเดียว เรื่องนี้เป็นส่วนหนึ่งของ **Context Engineering** หากไม่มีสิ่งนี้ Claude จะทำงานเหมือนผู้ช่วยทั่วไป; เมื่อมีแล้ว ก็ทำงานเหมือนเครื่องมือที่คาดเดาได้
การยกเลิกสามระดับนี้เป็นพื้นฐานของทักษะหนึ่งอย่าง: รู้วิธีกู้คืนสถานะเมื่อเกิดปัญหา ทักษะนี้เพียงอย่างเดียวค่อนข้างจำกัด แต่เมื่อรวมกับเครื่องมือ context engineering อื่น ๆ ก็กลายเป็นสิ่งที่มากกว่านั้น Plan Mode ไม่อนุญาตให้เขียนโค้ดทันที—ต้องเริ่มจากแผน ตามด้วยการยืนยัน แล้วจึงลงมือ นี่คือการป้องกันการต้องยกเลิก: คุณไม่เขียนสิ่งที่ต้องมายกเลิกภายหลัง เพราะได้ตรวจทานแผนล่วงหน้าแล้ว อ่านเพิ่มเติมได้ในคู่มือ [Plan Mode ใน Claude Code](https://ailoot.ai/blog/th/claude-code-plan-mode/) [CLAUDE.md](https://ailoot.ai/blog/th/claude-md-template/) กำหนดกฎที่ Claude เคารพโดยค่าเริ่มต้น รวมถึง Git Safety Protocol ที่กล่าวถึงข้างต้น นี่คือการป้องกันคำสั่งที่ทำลายข้อมูลล่วงหน้า [Second Brain](https://ailoot.ai/blog/th/claude-code-second-brain/) มอบความทรงจำเกี่ยวกับโปรเจกต์ให้ Claude ระหว่างเซสชัน—มันรู้ว่าคุณมีโค้ดอะไร ตรรกะทางธุรกิจเป็นอย่างไร และก่อนหน้านี้ตกลงอะไรกันไว้ ยิ่งมีความทรงจำมาก โอกาสที่มันจะทำผิดก็ยิ่งน้อยลง [Skills และ subagents](https://ailoot.ai/blog/th/claude-code-skills-library/) คือระเบียบวิธีของคุณที่เขียนเป็นโค้ด หากเวิร์กโฟลว์ git ที่ถูกต้องฝังอยู่ใน Skill ก็จะไม่มี subagent ตัวใดรัน `git reset --hard` โดยไม่ขอการยืนยัน ทั้งหมดนี้รวมกันคือ **Context Engineering** จัดการบริบทก่อนพรอมป์ต์ ไม่ใช่ระหว่างทำงาน อ่านเพิ่มเติมได้ในบทความ [context engineering คืออะไร](https://ailoot.ai/blog/th/context-engineering/) การยกเลิกคือแนวป้องกันด่านสุดท้าย ส่วน Plan Mode + CLAUDE.md + Second Brain + Skills คือสี่ด่านแรก เมื่อกำหนดค่าไว้ครบ การยกเลิกก็เกิดขึ้นไม่บ่อยและทำได้อย่างรวดเร็ว หากไม่มี ก็กลายเป็นพิธีกรรมประจำวัน
### แหล่งที่มา - [เอกสาร Anthropic - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [เอกสาร Anthropic - What's new (สัปดาห์ที่ 20, 11-15 พฤษภาคม 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)
การยกเลิกเริ่มต้นตรงที่การวางแผนสิ้นสุดลง [ไปที่ Ailoot](https://ailoot.ai/). ## คำถามที่พบบ่อย ### WIP checkpoint ควรใช้ git add . หรือไม่? ไม่ควร รัน `git status` กับ `git diff` stage เฉพาะไฟล์ตามชื่อที่ตรวจแล้ว แล้วตรวจ `git diff --cached` ก่อน commit checkpoint ตามเวลาไม่ได้อนุญาตให้รวมการแก้ไม่เกี่ยวข้องหรือสิ่ง staged ไว้ก่อน ### /rewind ย้อน migration ฐานข้อมูลหรือ API ระยะไกลได้หรือไม่? ไม่ได้ คู่มือจำกัด checkpoint ที่การแก้ไฟล์ที่รองรับในเซสชัน ฐานข้อมูล Git ระยะไกล และ API ต้องมีขั้นกู้แยก ส่วนไฟล์นอกขอบเขต checkpoint ใช้ Git หรือสำรอง ## Ailoot · บริษัทและพอร์ตโฟลิโอโครงการของบริษัท Ailoot อาศัยประสบการณ์การดำเนินงานที่สั่งสม ฐานลูกค้าขนาดใหญ่ บริการที่เสถียร และการติดตาม KPI อย่างต่อเนื่อง บริษัทและพอร์ตโฟลิโอโครงการของบริษัท: ลูกค้าหลายล้านราย; ยอดขายระดับหลายพันล้านต่อเดือน. Ailoot นำประสบการณ์การดำเนินงานนี้มาใช้เพื่อให้เข้าถึงฟังก์ชัน AI ผ่าน API ในผลิตภัณฑ์ของลูกค้า เอเจนต์ แอปพลิเคชัน และระบบอัตโนมัติ