git commit يُرسل الفهرس كاملًا لا المسارات التي أضفتها فقط

وصف المدير التقني لشركة Vodou، تشاد بريست، على dev.to حادثتين أودعت فيهما جلسات وكيلة تعمل في المستودع نفسه تغييرات بعضها بعضًا.

ثمانية مسارات و20 ملفًا متغيّرًا

في 9 سبتمبر 2026 أضافت جلسة وكيلة في مستودعه ثمانية مسارات إلى الفهرس، جميعها داخل مجلد البوابة MCP-servers/Vodou-Console/، ثم شغّلت git commit. كان رد Git هو "20 files changed". أما الملفات الاثنا عشر الأخرى فكانت تخصّ جلسة أخرى في المستودع نفسه، وقد كانت قد أضافت إلى الفهرس ثلاثة عشر ملفًا، بينها عيّنة اختبار من 466 سطرًا وجزء كبير من المحرّك.

لم تكن هذه المرة الأولى. في 28 يوليو 2026 أضافت جلسة ثلاثة مسارات لميزة lease، وشغّلت جلسة موازية git add بين أمر add وأمر commit، فاجتاح الإيداع مقطعًا من 185 سطرًا من خادم المحرّك، وأربعة ملفات تحت MCP-servers/brain/، وملف scripts/build-server-bundle.sh.

لماذا لا تكفي إضافة مسارات محدّدة

كانت قاعدة بريست آنذاك: أضف مسارات صريحة فقط، ولا تشغّل git add -A أبدًا. ويقول إنه وثق بهذه القاعدة نحو شهر وأخطأ: فالقاعدة تنظّم اختيار فاعل واحد ولا تغيّر ما يقرأه الإيداع.

git commit دون وسائط لا يُودع ما أضفته أنت بل الفهرس، وهناك فهرس واحد لكل شجرة عمل في المسار .git/index. كل جلسة في تلك الشجرة تقرأ الملف نفسه وتكتب فيه، لذا فإن أمر git add الواحد كتابة واحدة في ذاكرة تكتب فيها عمليات أخرى أيضًا. في يوليو كتبت عملية مجاورة داخل نافذته الزمنية، وفي سبتمبر كان عمل الجلسة المجاورة في الفهرس قبل أن تبدأ.

حلّان وحدود العزل

إذا أزلنا Git، فالعطل هو أي منطقة staging مشتركة قابلة للتغيير تلتقط خطوة النشر فيها صورة للمنطقة كاملة بدل مدخلات العمل المُعلنة. ويرى بريست ذلك، بين أمور أخرى، في وكلاء البرمجة المتوازيين الذين يتشاركون شجرة عمل واحدة.

الحل الأول هو git commit --only مع قائمة مسارات، إذ يُودع نسخة شجرة العمل من تلك المسارات فقط. وإذا حرّر وكيلان الملف نفسه فهذا لا يكفي، فانتقل إلى فهرس خاص: GIT_INDEX_FILE=/tmp/agent-a.index ثم git read-tree HEAD وgit apply --cached. وشجرة عمل منفصلة لكل وكيل نصيحة معيارية، لكنها لم تناسب مستودعًا يحرّر فيه الوكلاء نظامًا واحدًا قيد التشغيل ويحتاجون إلى رؤية تغييرات الآخرين مباشرةً.

وبعد الإيداع بفهرس خاص يصبح git status قديمًا ويُبلّغ عن حذف ملفات موجودة أصلًا في HEAD، لذا يتحقق بالأمر git cat-file -e HEAD:path. والخلاصة لأي نظام فيه أكثر من كاتب واحد: انظر إلى ما تقرأه خطوة النشر، لا إلى ما أضفته أنت.