> git undo وcancel وrevert — تغييراتك تبقى مهما كانت الكلمة التي كتبتها▋

يأتي git بخمسة أفعال لاستعادة كودك — undo وcancel وrevert وreset وrestore — ولا يُسمّى أي منها undo فعلًا. في مكان ما، قاموس مرادفات فخور جدًا بنفسه.

وهذا ما يكلّفه القاموس. الأسبوع الماضي، الاستعلام الرأسي لهذه العائلة — git undo last commit keep changes — جلب 73 ظهورًا في المركز 11.1 دون نقرة واحدة، بنمو +100% أسبوعًا بعد أسبوع، وبرفقاء أربعة يكتبون بطريقة مختلفة. الناس ليسوا في حيرة من git. هم يخافون من --hard، وكل درس نمطي يجيب على هذا الخوف بالعلم الوحيد الذي يثبته. هذه الصفحة تمرّ على العائلة من أعلى إلى أسفل: اختر فعلك، راجع الجدول، وبعد ذلك فقط المس السجل.

الفعل الذي يكتبه الناس	ما يفعله git فعلًا	يحفظ العمل؟	الأمر
"undo"	بطاقة الفرع تتراجع commit واحدة؛ التغييرات تعود إلى منطقة الـ staging	نعم — في الفهرس	git reset --soft HEAD~1
"cancel"	reset الافتراضي: البطاقة تتراجع والتغييرات تعود دون staging	نعم — في شجرة العمل	git reset HEAD~1
"revert"	يُضاف commit جديد يلغي القديم؛ السجل لا يُعاد كتابته أبدًا	نعم — كـ diff معاكس	git revert HEAD
"unstage"	المسارات تخرج من الفهرس؛ محتوى الملفات لا يُمس	نعم — لم يغادر شيء شجرة العمل	git restore --staged file.txt
"أجّلها جانبًا"	يُغلَّف العمل ويوضع على رفّ يمكنك العودة إليه	نعم — في كومة الـ stash	git stash push -m "wip"

القرار الوحيد المهم

• حدّد الـ commit: git log --oneline -3
• اطرح السؤال الوحيد: هل سحبه أحد غيرك؟
• غير مدفوعة → git reset --soft HEAD~1، وأعد الالتزام بنظافة
• مدفوعة → git revert HEAD، وادفع المعاكس
• شغّل git status بعدها لتتأكد أن عملك حيث تتوقعه

كيف أتراجع عن آخر commit مع الاحتفاظ بالتغييرات؟

git reset --soft HEAD~1 — بطاقة الفرع تتراجع commit واحدة وكل ما فعلته يعود جاهزًا في الـ staging. لا شيء يُحذف ولا شيء يغادر الفهرس؛ يمكنك إعادة الالتزام برسالة أفضل أو تقسيم العمل. الجولة الكاملة — حالة الدفع مشمولة — في git undo last commit: keep changes, stay safe.

verify: بعد الـ reset، ينبغي أن يُظهر git status ملفاتك تحت «Changes to be committed» — هذا عملك وهو يعود إليك.

هل يعني "git undo commit keep changes" شيئًا مختلفًا؟

لا — السؤال نفسه، والإجابة نفسها. «undo» لم يكن يومًا أمرًا في git؛ لوحتنا تري إن обоيتي الكتابة تستهدفان المشكلة ذاتها، وكلاهما يُحل بـ reset --soft. حين يقول الناس undo فإنهم يقصدون: حرّك البطاقة واحفظ العمل — وهذا كل ما فعله الـ soft reset في حياته.

لماذا إجابة "git revert last commit keep changes" مختلفة؟

لأن revert هو العضو الوحيد في العائلة الذي يضيف إلى السجل بدل أن يعيده للخلف. git revert HEAD ينشئ commit جديدًا يكون diff الخاص به هو ما يُلغي القديم — وجزء «الاحتفاظ بالتغييرات» يحدث تلقائيًا: الـ commit السيئ يبقى في السجل وشجرة العمل تنتهي بدونه. إنه الأداة الصحيحة فور سحب أحدهم الآخر للفرع؛ ومفترق reset مقابل revert مرسوم في git revert vs reset: which one saves your history?

revert = التراجع العلني. لا يعيد كتابة ما لدى الآخرين أبدًا؛ بل يُلغي التغيير بـ commit جديد جمعي.

هل "git cancel commit" أمر حقيقي؟

لا — cancel كلام محادثة، وترجمة git لهذا الكلام هي reset. «cancel commit but keep changes» و«cancel last commit but keep changes» — كتابتان إضافيتان في الأسبوع نفسه على لوحتنا — كلتاهما تنتهيان إلى git reset --soft HEAD~1. لا يهم git سوى البطاقة التي تحرّكها والعَلَم الذي تمرّره؛ والمفردات تجلبها أنت.

يمكنني حذف commit لم يسحبه أحد؟

نعم — الـ commit غير المدفوعة ما زالت ملكك ويمكن إعادة تشكيلها بلا عواقب. reset --soft يحفظ العمل، وreset HEAD~1 يحفظه دون staging، ووحده --hard يرميه — الفعل الوحيد الذي لا يحفظ شيئًا في هذه الصفحة. وإذا لم تكن الـ commit لك أصلًا ولا يشير إليها شيء، فمن يجمعها في النهاية git gc، لا أنت.

يمكن عمل stash لملف واحد فقط؟

نعم — git stash push -m "wip" -- src/app.ts يرفع مسارًا واحدًا ويترك بقية شجرتك سلامة. الفاصل -- هو ما يحصر الـ stash في المسارات المسمّاة. والحالات الحدّية للملف الواحد — بما فيها سبب نجاة الـ stash من checkout — تسكن في git stash a single file without losing the rest.

يمكن عمل cherry-pick لعدة commit؟

نعم — بنطاق: git cherry-pick A^..B يأخذ كل commit بعد A حتى B inclusive، بالترتيب. أضف -n إن أردتها في الـ staging ككتلة واحدة بدل التزامها واحدة واحدة. دفتر الصراعات للنطاقات العصيّة في git cherry pick: multiple commits, branches, conflicts.

كيف أعمل cherry-pick لعدة commit من فرع آخر؟

النطاق ذاته يعمل بين الفروع: git switch target && git cherry-pick A^..B. يحلّ git الـ commit من الفرع المصدر ويعيد تشغيلها على فرعك — توقّع صراعات حيث تباعد الفرعان، وعالجها واحدًا واحدًا لا دفعة واحدة.

هل أستطيع استعادة commit تُركت؟

تقريبًا دائمًا نعم — reflog يتذكّر أين كان HEAD نحو 90 يومًا افتراضيًا (gc.reflogExpire في git). اعثر على الـ hash الضائع عبر git reflog، ثم git reset --soft HEAD@{1} لإعادته تحت شجرة عملك. أنت لا تتراجع عن شيء — أنت تحرّك بطاقة بينما git يحفظ الإيصالات بصمت.

أي git undo أستخدم؟

الذي في الجدول أعلاه، بصراحة — وإن أردت أن تختار الآلة: مولّد git-undo يأخذ فوضاك كمدخل ويطبع الأمر الدقيق، ومقال إطلاقه يعرض التفكير حالةً حالة. وكل عملية استعادة مجرّبة في هذا العنقود مرصوفة في مركز git-undo.

الفخ في الغرفة: --soft و--mixed و--hard

العَلَم يقرر أين يهبط عملك، وواحد من الثلاثة فقط خطر. --soft يعيده بـ staging، و--mixed (الافتراضي) دونه، و--hard يوازن كل شيء مع الـ commit الهدف ويرمي الباقي. وإذا كتبت --hard في لحظة ذعر: ما زال الـ reflog يحتفظ بالـ commit نحو 90 يومًا — git reflog، ثم reset إلى الـ hash. الفعل الذي تكتبه في الثواني الخمس الأولى لا يحسم شيئًا إلى الأبد؛ يوميات git أطول من ندمك.

أي كتابة أوصلتك إلى هنا — undo أم cancel أم revert؟ قلها في التعليقات؛ المولّد يقبل الثلاث كلها، وأغرِبها يصبح المقال التالي. تقول اللوحة إن معظمكم كتب undo — كانت البيانات هنا قبل النصيحة.