استعادة commit بعد git reset --hard
تمثل المقاطع حالات مختلفة وليست سكربتاً واحداً. اختر الحالة المناسبة لمستودعك واستبدل أسماء الفروع والمسارات وVERIFIED_COMMIT قبل الاستخدام. أوامر الإلغاء تخص العملية النشطة المقابلة فقط؛ لا تنفذ البديلين معاً.
الجواب المختصر
بعد git reset --hard، ابحث عن commit السابق في reflog، وافحصه ثم أنشئ فرع إنقاذ. يجب أن يظل كائن commit موجودًا حتى تنجح الاستعادة.
المثال وشروطه
هذا المسار يستعيد العمل المسجل في commit. لا يحتفظ reflog بالتعديلات التي كانت موجودة في مجلد العمل فقط ولم تُسجل.
افحص الحالة قبل التعديل
توقف عن تنفيذ reset وrebase وتبديل الفروع مؤقتًا. اقرأ git reflog وافحص المحتوى باستخدام git show قبل نقل أي مرجع.
git status --short
git reflog --date=iso
git show VERIFIED_COMMITاحتفظ بمرجع أو نسخة عمل منفصلة
أنشئ rescue/lost-work عند VERIFIED_COMMIT. يمنح ذلك commit مرجعًا دون تغيير فرعك الحالي أو الكتابة فوق ملفات العمل.
git branch rescue/lost-work VERIFIED_COMMIT
git log -5 --oneline rescue/lost-workالمسار الأول
راجع سجل الفرع المستعاد والفروق. يمكنك فحصه في checkout آخر أو دمج التعديلات التي تحتاجها باختيار واضح.
اختر النتيجة الأخرى عن قصد
تنفيذ reset مباشرة إلى commit المستعاد يغيّر الفرع والفهرس والملفات مرة أخرى. احفظ تعديلاتك الحالية ومرجع الإنقاذ أولًا.
الحدود والاستثناءات
يشير HEAD@{1} إلى موضع في reflog، وليس بالضرورة commit المطلوب. قد يحتوي ORIG_HEAD على الطرف السابق، لكن عمليات أخرى تستطيع استبداله.
التعارضات والتنظيف
انتهاء سجلات reflog وتنظيف الكائنات سياستان منفصلتان قابلتان للضبط. لا يستطيع سجل قديم إعادة بناء كائن حُذف بالفعل.
تحقق من النتيجة
تحقق من commit والملفات وسجل فرع الإنقاذ. نفّذ الاختبارات المناسبة قبل دمج التعديلات.
git show --stat rescue/lost-work
git status --shortأسئلة شائعة
ينشئ git revert commit يعكس التغييرات، ولا يعيد الفرع إلى موضعه قبل reset. قد يجد git fsck كائنات blob لمحتوى أُضيف للفهرس فقط، دون ضمان أسماء الملفات أو بنيتها.
راجع العملية في FluxGit
يجمع FluxGit تحركات reflog ونقاط الاستعادة في Safety Timeline. عند تفعيل الميزة واكتشاف تعديلات محلية، يمكن لمسار reset المشمول حفظ stash أمان. لا يستخدم reset العادي في طرفية هذا الدرس تلك الحماية.
مراجع Git الرسمية
التراجع عن git reset --hard: استعد الالتزام المفقود
يمكن استعادة تغيير محفوظ في التزام بعد git reset --hard باستخدام reflog المحلي ما دام كائن الالتزام محفوظًا. لا تُضمن الاستعادة بعد انتهاء صلاحية reflog أو تنظيف الكائنات.
شاهد على YouTube — يفتح علامة تبويب جديدة
سُجّل في مستودع تجريبي.
اقرأ نص التعليق الصوتي
- نفّذت git reset --hard، فاختفى آخر التزام لك. يقع الجميع في هذا الخطأ مرة. إليك طريقة استعادته وسبب نجاحها.
- أولًا، عمل محفوظ في التزام: إعادة محاولة استدعاء الدفع مرتين.
- ثم في الطرفية: git reset --hard HEAD~1.
- يرصد FluxGit التغيير فورًا. عاد الفرع إلى موضع سابق، ولم يعد الالتزام عليه.
- إليك سبب عدم فقدانه. الفرع مجرد تسمية تشير إلى التزام. ينقل reset التسمية إلى الخلف، لكن الالتزام يبقى في المستودع، ويظل reflog، يوميات Git، يسجّله. أنشئ فرعًا عند ذلك الالتزام، وسيعود.
- في FluxGit، يشرح Recover lost work الأمر بكلمات بسيطة ويأخذك إلى المكان الصحيح.
- تعرض Safety Timeline عملية reset في جملة واحدة. أنشئ فرعًا من اللحظة التي سبقتها.
- عاد الالتزام، على فرع خاص به.
- العمل الذي لم تحفظه في التزام ليس في reflog. عند تفعيل نقاط الاستعادة ورصد تغييرات محلية، يمكن لـFluxGit حفظ stash احتياطي قبل hard reset. عملية reset في هذا المثال تُنفّذ باستخدام Git العادي في الطرفية وتتجاوز تلك الحماية.
- والأمر نفسه في الطرفية: استخدم git reflog، وابحث عن السطر السابق لعملية reset، وأنشئ فرعًا عند ذلك الالتزام.
- الخلاصة: ينقل reset التسمية، ويتذكر reflog أين كانت. أنشئ فرعًا للاحتفاظ بالالتزام. في الدرس التالي: استعادة فرع محذوف.