איך מבטלים שינויים ב-Claude Code: /rewind ו-git

מידע מעשי על עבודה עם Ailoot זמין בתיעוד.

מהי ביטול ב-Claude Code, ולמה שלוש רמות אינן מספיקות?#

הפעלתי את /rewind בשבוע הראשון שלי עם Claude Code, אחרי שהוא שיבש את לוגיקת האימות בפרויקט שלי בשתי הנחיות. חזרתי לאחור, נשמתי לרווחה והמשכתי. חודש אחר כך קרה מקרה נוסף: כתבתי הגירת סכימה, Claude עזר לי, ביצעתי commit, עברתי לענף אחר — ואז הבנתי ששכחתי שלב הכרחי. /rewind לא עזר — הסשן כבר היה אחר. git checkout לקומיט הקודם עזר. חודש לאחר מכן אמרתי לסוכן בטעות: „תחזיר הכול למצב של ה-push האחרון”, והוא הריץ git reset --hard והרס שלוש שעות עבודה. git reflog הציל אותי — הגיבובים של הקומיטים שנהרסו עדיין היו שם.

שלושת הסיפורים האלה מייצגים שלוש רמות הגנה שעובדות בדרכים שונות, תופסות שגיאות שונות ונחוצות כולן. המדריך הזה מסביר כל רמה, עם הפקודות, המגבלות והדוגמאות שלה, ומראה גם כיצד להגדיר פרויקט מראש כדי ש-Claude לא יפיל אותו בפעם הראשונה.

3 רמות ביטול — מה ומתי:

בהמשך נעבור על כל רמה — מה בדיוק לעשות, אילו מלכודות יש, ואיך להגדיר את הדברים כך שלא יהיה מה לבטל, כי שום דבר לא נשבר.

איך מפעילים את /rewind: בפקודה או באמצעות Esc-Esc?#

אחרי כל תשובה, 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:

הפקודה /rewind עושה אותו דבר — היא פותחת את התפריט. יש גם כינוי, /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 לא מבטל דבר; הוא רק דוחס — ההודעות המקוריות נשארות בתמליל הסשן לעיון, אבל רק הסיכום נשאר בהקשר הפעיל. השתמשו ב-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 בתור, השינויים האלה לא ייכללו בנקודת הביקורת. התיעוד של Anthropic מציין זאת במפורש:

פירוש הדבר הוא שאם Claude מוחק, מעביר או מעתיק קובץ בעצמו באמצעות כלי Bash, /rewind לא ישחזר הכול. git checkout או שחזור מגיבוי יכולים לעזור, אבל הדבר דורש יותר מלחיצה על שני מקשים.

2. עריכות חיצוניות אינן נלכדות. אם פתחתם קובץ ידנית ב-VS Code וערכתם אותו, או סשן Claude שני משנה את אותם קבצים במקביל, הסשן הראשון לא יכול לראות את השינויים האלה. תמונת מצב של נקודת ביקורת נוצרת כש-Claude מסיים תור בסשן הנוכחי. מה שקורה בין תורים אינו באחריותה.

3. פעולות מחוץ לקבצים אינן מכוסות כלל. הגירת Prisma שהוחלה באמצעות npx prisma migrate dev שינתה את סכימת מסד הנתונים — /rewind לא יבטל אותה, כי מסד הנתונים נמצא מחוץ למערכת הקבצים של הפרויקט. force-push אל origin/main הוא אותו סוג פעולה: הקומיט הגיע לשרת המרוחק, ונקודת הביקורת לא תחזיר אותו. קריאת API מרוחקת שחייבה כסף או מחקה רשומה אפשר לבטל רק באמצעות המנגנונים של ה-API עצמו.

כלל: אם משימה משפיעה על משהו מחוץ לקובצי הפרויקט — הגירות מסד נתונים, git push או APIs מרוחקים — הכינו אסטרטגיית rollback נפרדת לכל השפעה חיצונית. /rewind הוא היסטוריית הקבצים המקומית בלבד, בתוך הסשן הנוכחי.

/rewind לעומת git: מה ההבדל ביניהם, ולמה צריך את שניהם?#

התיעוד של Anthropic מציין במפורש את השילוב הזה:

ההבדלים בטבלה אחת:

השילוב פשוט: בכל פעם שמגיעים למצב שבו „זה עובד, ואני לא רוצה לאבד את זה”, מבצעים git commit. בין קומיטים מסתמכים על /rewind — הוא מיידי, לא דורש הודעת commit ולא מעמיס על היסטוריית git במצבי ביניים. כשהעבודה מסתיימת, מבצעים commit — ועדיף שיהיה משמעותי ואטומי.

למה /rewind אחד לא מכסה את כל המשימה?#

ביטול הוא מקרה אחד של הנדסת הקשר. נהלו את ההקשר בסשן (מתי לבצע 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. השנייה הייתה הרסנית: היא שכתבה את הענף לקומיט 35eb731, וכל הקומיטים שבינו לבין 882e618 הפכו ליתומים. כברירת מחדל, קומיטים יתומים נשארים ב-.git/objects/ עד ש-git gc רץ, מה שבדרך כלל מתרחש אוטומטית בתוך שבועיים. אבל אם לא ידעתם מה לעשות באותו רגע, הזמן כבר פעל לרעתכם.

ההיגיון פשוט: בשפה טבעית, „לחזור לאחור”, „לחזור”, „לשחזר”, „להחזיר” ו„לבטל” פירושם „להסתכל אחורה” או „לחזור למקום בטוח”. הם לא פירושם „להרוס את ההיסטוריה”. הפקודה git reset --hard הורסת אותה — היא משכתבת את הענף ומסירה קומיטים מבין אלה שנגישים דרך HEAD. חלופה בטוחה היא git checkout <commit>, שיוצרת HEAD מנותק ומאפשרת לראות את המצב הישן בלי לגעת בענפים.

הלקח המעשי העיקרי הוא לבצע git commit למצב הנוכחי לפני כל משימה משמעותית, במיוחד לפני שינוי מבני בכמה קבצים. commit אחד הופך כל טעות של Claude לפקודת git checkout . אחת, בלי לאבד עבודה.

איך git reflog מציל אתכם אחרי איפוס הרסני?#

אחרי 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} הם אותם קומיטים „הרוסים”. הם לא נעלמו ממאגר האובייקטים המקומי של git; הם פשוט נעשו בלתי נגישים דרך הענף. כדי לשחזר אותם:

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

# Or switch directly
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. אם commit היה רק ב-stash וה-stash הושמד, ה-reflog יציג רק את המצב האחרון של ה-stash, ולא את ההיסטוריה הפנימית שלו.

כלל לצוות: לעולם אל תריצו git gc --aggressive מיד אחרי אסון. קודם חקרו באמצעות reflog ושחזרו; את כל השאר עשו אחר כך. ואל תמחקו לעולם את השיבוט המקומי של המאגר לפני שאתם בטוחים שכל מה שנחוץ לכם נדחף לשרת.

איך מגינים על פרויקט מפני פקודות 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 שבשורש המאגר):

## Git Workflow Rules

- בצעו commit בכל אבן דרך עובדת. לפני commit של עבודה בתהליך, הריצו `git status` ו-`git diff`, הוסיפו לאזור ההכנה רק קבצים בשמות מפורשים שבדקתם באמצעות `git add -- path/to/file`, ואז בדקו את הבדלי הקבצים המוכנים לפני ה-commit. טיימר מזכיר לבדוק התקדמות; הוא אינו אישור להוסיף את כל עץ העבודה.
- 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 האחרון” יוביל לתשובה כזו:

אני רואה 3 קבצים עם שינויים שטרם בוצע להם commit ו-4 קומיטים מאז ה-push האחרון. שתי אפשרויות:

1. בטוחה: ליצור ענף view-last-push באמצעות git checkout <last-push-hash> — אשמור על כל העבודה, אבל אציג זמנית את המצב של ה-push.
2. הרסנית: git reset --hard <last-push-hash> — אשמיד לצמיתות 4 קומיטים ואת השינויים שטרם בוצע להם 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> — חזרה לקומיט ישן בלי לאבד היסטוריה.

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

זו „חזרה זמנית” בטוחה. HEAD מנותק אינו משנה את הענף; העבודה הנוכחית שלכם ב-main (או בענף שבו הייתם) נשארת שלמה. אם רוצים לעבוד במצב הזה, יוצרים ענף.

רמה 4. git reset --hard <commit> — החזרת הענף לנקודה קודמת.

⚠️ הרסני. קומיטים שאחרי הגיבוב שצוין הופכים ליתומים.

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

השתמשו בכך רק אם אתם בטוחים שאינכם זקוקים לקומיטים שאחריו. ותמיד בדקו git reflog לפני האיפוס, כדי שתדעו לאן לחזור אם תשנו את דעתכם.

רמה 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, שיציג קומיטים תלויים ב-.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, שמרו על אותו כלל בדיקה והוספת נתיבים מפורשים לאזור ההכנה. אל תהפכו טיימר ל-commit אוטומטי ללא בדיקה: אחרת עריכות לא קשורות או קבצים שכבר הוכנו עלולים להיכלל ב-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/ לניסויים ולהערות שלי, שאסור לכלול במאגר המשותף. התיקיות .claude/sessions/ ו-.claude/file-history/ הן האחסון המקומי של Claude Code; הן לא שייכות למאגר, תופסות מקום רב וקשורות למחשב מסוים.

כלל 3. עורכים ניסויים בענף נפרד.

אם המשימה גדולה (שינוי מבני ב-10+ קבצים, מעבר למסד נתונים חדש, שכתוב מודול), אל תעבדו בענף הראשי:

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 הרס ענף אחד, מחקתי אותו ואנחנו מתחילים מחדש”.

כלל 4. לפני פעולות מסוכנות משתמשים ב-git tag.

לפני הגירת מסד נתונים, שינוי מבני גדול או עדכון תלות, יוצרים tag:

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 הוא מצביע בעל שם לקומיט שלא תאבדו גם אחרי ניקוי ה-reflog.

מה הלאה: איך ביטול משתלב בהנדסת הקשר?#

שלוש רמות הביטול האלה הן התשתית למיומנות אחת: לדעת לשחזר מצב כשהוא מתקלקל. המיומנות הזו צרה בפני עצמה. אבל בשילוב עם כלי הנדסת הקשר אחרים, היא הופכת למשהו רחב יותר.

Plan Mode לא מאפשר לכתוב קוד מיד — קודם באה התוכנית, אחר כך אישור, ורק אז ביצוע. זהו ביטול מונע: לא כותבים משהו שיצטרכו לבטל מאוחר יותר, כי התוכנית נבדקה מראש. קראו עוד במדריך ל-Plan Mode ב-Claude Code.

CLAUDE.md מגדיר כללים ש-Claude מכבד כברירת מחדל, כולל Git Safety Protocol שסקרנו למעלה. זוהי הגנה מונעת מפני פקודות הרסניות.

המוח השני נותן ל-Claude זיכרון על הפרויקט בין סשנים — הוא יודע איזה קוד יש לכם, מהי הלוגיקה העסקית ואילו הסכמות נעשו קודם. ככל שיש יותר זיכרון, כך קטן הסיכוי שיעשה את הדבר הלא נכון.

Skills וסוכני משנה הם המתודולוגיה שלכם בקוד. אם תהליך העבודה הנכון עם git מובנה ב-Skill, שום סוכן משנה לא יריץ git reset --hard בלי אישור.

וכל זה יחד הוא הנדסת הקשר. נהלו את ההקשר לפני ההנחיה, ולא במהלכה. קראו עוד ב-מהי הנדסת הקשר.

ביטול הוא קו ההגנה האחרון. Plan Mode + CLAUDE.md + Second Brain + Skills הם ארבעת הראשונים. כשהם מוגדרים, הביטול נעשה נדיר ומהיר. כשהם לא מוגדרים, הוא נעשה טקס יומי.

הביטול מתחיל במקום שבו התכנון מסתיים.

עברו אל Ailoot.