مولّد git undo: الأمر الدقيق لفوضك

كان أحد الزملاء يجيب عن كل سؤال تراجع بـ «git reset --hard»، كما يجيب آخرون بـ «أطفئه وشغّله». نجح ذلك مرتين. أما الثالثة فكلّفتها جمعة بعد الظهر ودرس reflog لم يفرح به أحد. نشأ مركز Undo Anything in Git في هذا الموقع من ذلك الأسبوع — واليوم ينضم إليه أداة حقيقية.

مولّد git undo يعمل الآن: ثلاثة أسئلة تدخل، أمر واحدة دقيقة تخرج. بلا حساب وبلا رفع أي شيء — كل شيء يجري في متصفحك. حدّد هل رُفع الـ commit، وهل تحتفظ بالتغييرات، وهل يسحب غيرك الفرع؛ فيطبع الأمر الصحيحة git reset أو git revert أو إنقاذ reflog، مع تحذير في المواضع التي تعضّ فيها الأمر.

لماذا أداة لأربعة أوامر؟

لأن بيانات البحث تقول إن الناس يريدون الجواب لا المقالة. تُظهر Google Search Console هذا الموقع في المركز 12.3 لعبارة «git reset last commit keep changes» — 27 ظهورًا في أسبوع، وبلا نقرة واحدة. العبارة تطلب أمرًا بصوت مسموع، والباحث يتجاوز أي شيء يُلزمه بالقراءة. المولّد يجيب في شاشة واحدة.

النمط نفسه يتكرر في كل الصيغ: «and keep changes» و«but keep changes» و«keep the file». هؤلاء لا يدرسون نظرية التحكم بالإصدارات. لديهم فوضى الآن، ويريدون أقصر مخرج منها.

كيف يقرر المولّد

ثلاثة أسئلة، مأخوذة كما هي من دليل revert مقابل reset:

1. أين الـ commit؟ غير مرفوع، مرفوع، أو مفقود تمامًا.
2. ماذا يحدث للتغييرات؟ تُحفظ مُجهّزة، تُحفظ غير مُجهّزة، أو تُهمَل.
3. من غيرك يسحب هذا الفرع؟ السؤال الذي يفصل بين إعادة كتابة نظيفة وحادثة فريق.

سؤال الفرع المشترك هو الأداة كلها. ما سواه ترف؛ ذلك سؤال إدارة الكوارث.

إجاباته كاملة:

الأمر	التاريخ	شجرة العمل	فرع مشترك؟
git reset --soft HEAD~1	يتراجع 1	التغييرات محفوظة ومُجهّزة	لا — إعادة كتابة
git reset HEAD~1	يتراجع 1	التغييرات محفوظة غير مُجهّزة	لا — إعادة كتابة
git reset --hard HEAD~1	يتراجع 1	التغييرات تهمَل	لا — مدمّر
git revert HEAD	يضيف commit عكسيًا	بلا مساس	نعم — الخطوة الآمنة
git reflog + git switch -c recovery <sha>	لا شيء مفقود	تُستعاد من reflog	إنقاذ بعد أي شيء

الأوامر التي يطبعها

كل الحالات التي يغطيها المولّد، جاهزة للّصق:

# بعد commit وبدون رفع، احتفظ بالتغييرات مُجهّزة
git reset --soft HEAD~1

# بعد commit وبدون رفع، احتفظ بالتغييرات غير مُجهّزة
git reset HEAD~1

# مرفوع وغيرك يسحب الفرع — التراجع المهذب الوحيد
git revert --no-edit HEAD~1..HEAD
git push

# بعد commit وفُقد — الـ reflog يعرف نحو 90 يومًا
git reflog
git switch -c recovery <sha من القائمة>

صيغة النطاق HEAD~1..HEAD تتراجع عن الـ commits التي تسمّيها تحديدًا دون إعادة بنائها واحدًا واحدًا — تستحق أن تعرفها حتى حين تكتبها الأداة عنك.

تحت الغطاء

المنطق جدول قرارات، لا سحر. ثلاثة أسئلة تعطي ثماني عشرة تركيبة؛ معظمها ينكمش إلى الحفنة نفسها من الأوامر، لأن «غير مرفوع + إهمال» و«مرفوع + فرعي وحدي + إهمال» يختلفان بذيل force-with-lease فقط. الصفحة مسار ثابت — بلا خادم، بلا تحليلات، بلا كوكيز — فتفتح على هاتف داخل غرفة خوادم، حيث تقع معظم طوارئ git، وزر النسخ يسلّمك الكتلة كاملة مع تعليقات التحذير.

ما يرفضه عن عمد

لا مساعدة في rebase التفاعلي — إن كنت تعيد ترتيب الـ commits فأنت تعرف أكثر مما تعلّم الأداة. ولا جراحة stash؛ فلذلك دليلها الخاص. وهو يأبى التخمين: حين تكون الحالة «مرفوع على فرع مشترك» فالأمر الوحيد الذي يعرضه هو revert، لأن البدائل تحرق الفرق. الدليل الموسّع للتراجع عن commit يشرح ما يفعله كل flag بالـ reflog؛ الأداة ببساطة تمنعك من اختيار الخطأ على عجل. وحين يكون الاختيار بين أمرَي التراجع نفسَيهما، git revert vs reset يوضّح أيّهما يحفظ تاريخك.

المصدر على github.com/mrsaynothing/git-undo — HTML وJavaScript خالصان، بلا خطوة بناء، بلا اعتماديات. انسخه وغيّر أسلوبه وخذ صياغتي كما هي. نسخة هذا الموقع تشغّل المنطق نفسه كصفحة SvelteKit ثابتة.

إن وفّر عليك جلسة reflog واحدة هذا العام، فقد دفع ثمن العشية التي كلّفتها. وإن أعطى جوابًا خاطئًا في حالة واجهتها، فقائمة issues في المستودع مفتوحة لهذا بالذات.