كيفية التراجع عن التغييرات في Claude Code: /rewind وgit

تجد في الوثائق معلومات عملية عن العمل باستخدام Ailoot.

ما التراجع في Claude Code، ولماذا لا تكفي ثلاثة مستويات؟#

فعّلت /rewind في أسبوعي الأول من استخدام Claude Code، حين أفسد منطق المصادقة في مشروعي خلال promptين. تراجعت، وتنهدت بارتياح، ثم واصلت العمل. وبعد شهر، واجهت موقفًا آخر: كنت أكتب ترحيلًا للمخطط، وساعدني Claude، ثم أجريت commit وانتقلت إلى فرع آخر، وأدركت أنني نسيت خطوة ضرورية. لم يفدني /rewind؛ فقد أصبحت الجلسة مختلفة. أفادني git checkout إلى commit السابقة. وبعد شهر آخر، طلبت من الوكيل بالخطأ: «أعِد كل شيء إلى آخر push»، فنفّذ git reset --hard وأهدر ثلاث ساعات من العمل. أنقذني git reflog؛ فقد ظلت تجزئات commits المحذوفة موجودة.

توضح هذه القصص الثلاث مستويات الحماية الثلاثة: تعمل بطرق مختلفة، وتلتقط أخطاء مختلفة، وكلها ضرورية. يشرح هذا الدليل كل مستوى بأوامره وقيوده وأمثلته، ويوضح أيضًا كيفية إعداد المشروع مسبقًا حتى لا يُسقطه Claude من أول مرة.

مستويات التراجع الثلاثة — ما الذي يغطيه كل منها ومتى؟

سنستعرض الآن كل مستوى: ما الذي ينبغي فعله تحديدًا، وما المزالق، وكيفية الإعداد بحيث لا يكون هناك ما يستدعي التراجع لأن شيئًا لم ينكسر.

كيف تستدعي /rewind: بكتابة الأمر أم بالضغط على 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؛ فهي أسرع ولا ترفع يديّ عن لوحة المفاتيح.

أوضاع 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، يعود النص الأصلي للـ prompt المحدد إلى حقل الإدخال؛ ويمكنك تعديله وإرساله مجددًا. أما بعد 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: فقد وصل commit إلى الخادم البعيد، ولن تعيده نقطة التحقق. ولا يمكن التراجع عن استدعاء API بعيد حمّل رسومًا أو حذف سجل إلا عبر آليات API نفسها.

قاعدة: إذا أثّرت المهمة في شيء خارج ملفات المشروع — مثل ترحيلات قاعدة البيانات أو git push أو واجهات API البعيدة — فضع استراتيجية تراجع منفصلة لكل أثر خارجي. يقتصر /rewind على سجل الملفات المحلي ضمن الجلسة الحالية.

ما الفرق بين /rewind وgit، ولماذا تحتاج إلى كليهما؟#

توضح وثائق Anthropic هذا الجمع مباشرةً:

إليك الفروق في جدول واحد:

الجمع بينهما بسيط: كلما وصلت إلى حالة تقول فيها «هذا يعمل، ولا أريد خسارته»، أنشئ git commit. وبين commits، اعتمد على /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

كان الأمر الأول صحيحًا؛ فقد حفظ التغييرات غير المعتمدة في stash. أما الثاني فكان تدميريًا: أعاد كتابة الفرع إلى commit 35eb731، وأصبحت جميع commits الواقعة بينه وبين 882e618 يتيمة. افتراضيًا، تبقى commits اليتيمة في .git/objects/ حتى تشغيل git gc، وهو ما يحدث تلقائيًا عادةً خلال أسبوعين. لكن إن لم تكن تعرف ما ينبغي فعله في تلك اللحظة، فقد بدأ الوقت يعمل ضدك بالفعل.

المنطق بسيط: تعني عبارات «العودة» و«الرجوع» و«الاستعادة» و«التراجع» و«الإلغاء» في اللغة الطبيعية «راجع السجل» أو «ارجع إلى مكان آمن». ولا تعني «دمّر السجل». يدمّر الأمر git reset --hard السجل؛ إذ يعيد كتابة الفرع ويزيل commits التي لم يعد الوصول إليها ممكنًا من 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} هي تلك الـ commits «المحذوفة». لم تختفِ من مخزن كائنات 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، ملف prompt النظام الخاص بالمشروع.

قاعدة مختصرة (أدرجها في CLAUDE.md):

## بروتوكول أمان Git

- لا تشغّل أبدًا أوامر git التدميرية (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) ما لم أطلب هذه الإجراءات صراحةً. فالإجراءات التدميرية غير المصرّح بها لا تساعد، وقد تؤدي إلى فقدان العمل.
- عندما أقول "roll back" أو "go back" أو "restore" أو "revert" أو "undo"، ففسّر ذلك على أنه طلب لمراجعة الحالة: استخدم `git log` أو `git diff` أو `git checkout <commit>` (ينشئ HEAD منفصلًا) أو `git stash` (يحفظ التغييرات).
- اطلب التأكيد دائمًا قبل أي أمر:
  - يغيّر موضع HEAD إلى commit مختلف على أحد الفروع
  - يعدّل سجل commits
  - قد يؤدي إلى فقدان عمل غير معتمد
  - يتضمن العلامات --hard أو --force أو --aggressive
- قبل أي أمر تدميري، اعرض مقارنة مرقّمة:
  - آمن: استخدم `git checkout <commit>` للاطلاع مؤقتًا.
  - تدميري: استخدم `git reset --hard` للتدمير نهائيًا.
- انتظر اختياري الصريح قبل التنفيذ.

قاعدة موسّعة للفريق (أضفها إلى CLAUDE.md في جذر المستودع):

## قواعد سير عمل Git

- أنشئ commit عند كل مرحلة تعمل. قبل commit لـ WIP، نفّذ `git status` و`git diff`، وأضف فقط الملفات المسماة التي راجعتها صراحة باستخدام `git add -- path/to/file`، ثم افحص الفروق المرحلية قبل التثبيت. المؤقت تذكير للمراجعة، وليس إذنًا بإضافة شجرة العمل كاملة.
- لا تستخدم أبدًا `git add .` أو `git add -A` لإجراء commits بواسطة Claude. حدّد الملفات بأسمائها فقط، بعد `git status` + `git diff`.
- قبل تنفيذ `git push --force` إلى main، توقّف واسألني. في فروع الميزات، استخدم force-push بحذر، وفقط إذا كنت متأكدًا أنني مستعد لفقدان النسخة السابقة.
- عند حل تعارضات الدمج، لا تختَر "ours" أو "theirs" فورًا؛ اعرض عليّ النسختين أولًا، ثم أقرر.
- يجب أن يحتوي `.gitignore` على `.env*` و`.claude/personal/` و`node_modules/` و`dist/`. أضفها إذا كانت مفقودة.

بعد إضافة هذه القواعد، ستؤدي عبارة «عُد إلى آخر push» إلى الرد التالي:

أرى 3 ملفات لم تُعتمد و4 commits تسبق آخر push. أمامك خياران:

1. آمن: أنشئ فرع view-last-push باستخدام git checkout <last-push-hash>؛ سأحافظ على كل العمل، وأعرض مؤقتًا الحالة التي وصل إليها push.
2. تدميري: git reset --hard <last-push-hash> — سأدمّر نهائيًا 4 commits والتغييرات التي لم تُعتمد. لن يمكن استعادتها إلا عبر git reflog خلال 90 يومًا. أي الخيارين تختار؟

هذه محادثة تستغرق نصف دقيقة بدلًا من أربع ساعات من العمل الضائع.

ما الطرق الخمس للتراجع في Claude Code، وكيف تختار الطريقة المناسبة؟#

في سيناريو «أفسد Claude المشروع وأحتاج إلى استعادته بسرعة»، اصعد هذا السلم من أدنى درجاته. ابدأ دائمًا بالمستوى 1.

المستوى 1. /rewind — تراجع فوري ضمن الجلسة.

اضغط Esc Esc أو اكتب /rewind. اختر النقطة التي تسبق الخطأ. اختر وضعًا (غالبًا Restore code and conversation). وبعد لحظة تعود إلى الماضي ويمكنك البدء من جديد. يغطي 80% من حالات «نفّذ Claude الشيء الخطأ».

المستوى 2. git checkout . — التراجع عن جميع التغييرات غير المعتمدة.

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)، أو حين تحتاج إلى التراجع عن تغييرات خارج سجل الجلسة. ستختفي نهائيًا جميع التغييرات التي لم تُعتمد. إذا كنت قد تندم على ذلك، فنفّذ 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

هذه «عودة مؤقتة» آمنة. لا يغيّر HEAD المنفصل الفرع؛ فيظل عملك الحالي في main (أو أي فرع كنت تعمل عليه) سليمًا. إذا أردت العمل على هذه الحالة، فأنشئ فرعًا.

المستوى 4. git reset --hard <commit> — إعادة الفرع إلى نقطة سابقة.

⚠️ تدميري. تصبح commits التي تسبق التجزئة المحددة يتيمة.

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

استخدمه فقط إذا كنت متأكدًا من أنك لا تحتاج إلى commits التي تسبق ذلك الموضع. وافحص 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، الذي يعرض commits المعلّقة في .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 قبل العمليات الخطيرة.

أنشئ وسمًا قبل ترحيل قاعدة بيانات أو إعادة هيكلة كبيرة أو تحديث اعتماد:

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

الوسم مؤشر مُسمّى إلى commit، ولن تفقده حتى عند تنظيف reflog.

ما الخطوة التالية: ما علاقة التراجع بهندسة السياق؟#

توفر مستويات التراجع الثلاثة البنية التحتية لمهارة واحدة: معرفة كيفية استعادة حالة عند حدوث خلل. وهذه المهارة محدودة بمفردها، لكنها تصبح أكثر أهمية عند جمعها بأدوات أخرى لهندسة السياق.

لا يتيح Plan Mode كتابة الكود فورًا؛ إذ تأتي الخطة أولًا، ثم التأكيد، ثم التنفيذ. إنه تراجع وقائي: لن تكتب ما ستضطر إلى التراجع عنه لاحقًا لأن الخطة روجعت مسبقًا. اقرأ المزيد في دليل Plan Mode في Claude Code.

يضع CLAUDE.md قواعد يحترمها Claude افتراضيًا، بما فيها بروتوكول أمان Git الذي تناولناه أعلاه. وهذه حماية وقائية من الأوامر التدميرية.

يمنح Second Brain Claude ذاكرة بالمشروع بين الجلسات؛ فيعرف الكود الموجود ومنطق العمل والاتفاقات السابقة. وكلما زادت الذاكرة، قلّ احتمال أن يفعل الشيء الخطأ.

Skills والوكلاء الفرعيون هم منهجيتك مكتوبة في صورة كود. إذا أُدرج سير عمل Git الصحيح في Skill، فلن ينفّذ أي وكيل فرعي git reset --hard من دون تأكيد.

وكل ذلك معًا هو Context Engineering. أدر السياق قبل prompt، لا أثناءه. اقرأ المزيد في ما هندسة السياق.

التراجع هو خط الدفاع الأخير. أما الخطوط الأربعة الأولى فهي Plan Mode وCLAUDE.md وSecond Brain وSkills. عندما تُعدّ، يصبح التراجع نادرًا وسريعًا. وإذا لم تُعدّ، يصبح طقسًا يوميًا.

يبدأ التراجع حيث ينتهي التخطيط.

افتح Ailoot.