تخطَّ إلى المحتوى

١٣ يوليو ٢٠٢٦

حل حالة detached HEAD في Git بالعربي

شارك المقال:

كتبت git checkout لرقم commit قديم لتلقي نظرة، فاستقبلك Git بأطول تحذير في تاريخه:

You are in 'detached HEAD' state. You can look around, make
experimental changes and commit them, and you can discard any
commits you make in this state without impacting any branches...

اسم مرعب («رأس مقطوع»!) لحالة بريئة تمامًا — لنفهمها فتتحول من ذعر إلى أداة.

ماذا يعني «الرأس المنفصل»؟

HEAD هو مؤشر «أين أنت الآن». طبيعيًا يشير إلى فرع (main مثلًا)، والفرع يشير لآخر commit — فكل commit جديد يحرك الفرع معك.

عند checkout لرقم commit مباشرة، يقفز HEAD فوق الفروع كلها ويقف على الـ commit نفسه: أنت الآن «سائح» في نقطة زمنية — ترى المشروع كما كان بالضبط، وأي فرع لا يتحرك معك.

تفعلها عادة عبرمثال
زيارة commit قديمgit checkout abc1234
فحص وسم إصدارgit checkout v2.0
أثناء rebase تفاعلي أو bisectحالات مؤقتة مدارة تلقائيًا

السيناريو الآمن: سائح يتفرج ويعود

جئت تقرأ كودًا قديمًا فقط؟ تجوّل براحتك ثم عد لديارك:

git switch main     # عدت — وHEAD التصق بالفرع من جديد

انتهى. لا شيء حدث، ولا شيء كان سيحدث.

السيناريو الخطر الوحيد: بنيت شيئًا هنا

جربت فكرة وكتبت commits داخل الحالة المنفصلة؟ هذه الـ commits لا يحملها أي فرع — إن غادرت الآن أصبحت «يتيمة» وسيكنسها Git لاحقًا.

الإنقاذ قبل المغادرة — سطر واحد:

git switch -c experiment-rescue
# فرع جديد وُلد هنا حاملًا كل commits تجربتك — صارت بأمان للأبد

غادرت فعلًا قبل الإنقاذ؟ الوقت لم يفت غالبًا:

git reflog                    # سجل كل تحركات HEAD — ابحث عن commit تجربتك
git branch rescue abc9876     # اربطه بفرع وانتهى الرعب

💡 reflog هو «التأمين الخفي» في Git — يحفظ تحركاتك حتى خارج الفروع لأسابيع. احفظ وجوده لكل حوادث «ضاع عملي!».

كيف تتجنبها أصلًا؟

  • للتنقل بين الفروع استخدم git switch اسم-الفرع — لا تقع بالحالة خطأً معها.
  • أردت البناء على نقطة قديمة؟ أنشئ فرعًا منها فورًا بدل زيارتها:
git switch -c fix-old-bug abc1234   # فرع جديد من commit قديم — بلا انفصال
  • تعرف أنك ستزور فقط؟ ادخل بوعي واخرج بـ switch — الحالة صديقة للزائر الواعي.

قائمة تحقّق سريعة

  • الرسالة ظهرت؟ اهدأ — لا شيء ضاع، أنت «زائر» فقط.
  • تفرجت فقط؟ → git switch main وانتهى.
  • كتبت commits هنا؟ → قبل أي مغادرة: git switch -c اسم-جديد.
  • غادرت وضاعت؟ → git reflog ثم git branch rescue <hash>.
  • مستقبلًا: switch للتنقل، وفرع جديد فوري لأي بناء على القديم.

الخلاصة

detached HEAD ليست عطلًا بل وضع «زيارة بلا فرع». القاعدة كلها: تفرّج بحرية وعد بـ switch — وإن بنيت شيئًا فاربطه بفرع قبل المغادرة، وreflog شبكة أمانك إن نسيت.

أكمل إتقان الفروع في مسار Git بالعربي، ومعه ثلاثية الإنقاذ: حل failed to push و حل Merge Conflict و حل not a git repository.

📚 مصادر رسمية للتعمّق: التوثيق الرسمي لـ Git

الأسئلة الشائعة

هل detached HEAD خطأ يجب إصلاحه فورًا؟

ليست خطأ أصلًا بل حالة مشروعة: أنت «تزور» commit محددًا خارج أي فرع — مفيدة لفحص إصدار قديم أو تجربة فكرة سريعة. تصبح مشكلة فقط إذا أنشأت commits جديدة فيها ثم غادرت دون ربطها بفرع — حينها تصير «يتيمة» وتُحذف لاحقًا بكنس Git الدوري.

كتبت commits في هذه الحالة وغادرت — هل ضاعت للأبد؟

غالبًا لا: git reflog يعرض سجل كل تحركات HEAD الأخيرة حتى خارج الفروع. اعثر على hash آخر commit لك فيه، ثم أنقذه: git branch rescue <hash> — الكنس الدوري يمهلك أسابيع عادة، فكلما أسرعت كان الاسترجاع مضمونًا أكثر.

ما الفرق بين git switch و git checkout؟

checkout التاريخية تفعل كل شيء (تنقّل بين فروع، زيارة commits، استرجاع ملفات) وهذا سبب حوادثها. قُسمت حديثًا إلى أمرين أوضح: switch للتنقل بين الفروع وإنشائها، وrestore لاسترجاع الملفات. استخدم switch للتنقل — أصعب أن تقع بحالة detached بالخطأ معها.

اقرأ أيضًا

تصفّح كل المقالات في المدوّنة، أو ابدأ التعلّم من المسارات و خرائط الطريق.