# مقالة تقترح محرك تخزين جديدًا تحت Git بسبب ضغط الـ agents والمستودعات الضخمة

> **المغزى:** الأدوات التي تعمل فوق Git تغيرت كثيرًا خلال سنتين، بينما الطبقة التي تحتها عمرها عشرون عامًا، والـ agents التي تفتح فروعًا بالعشرات تكشف الفجوة.

- المصدر: المغزى (https://almaghza.com/a/2026-09-11-git-storage-engine-agents/)
- التاريخ: 29 ربيع الأول - 11 سبتمبر 2026 (2026-09-11)
- القسم: برمجيات
- الوسوم: Git، AI Agents، أدوات المطورين

نشرت شركة ERSC على مدونتها في 10 سبتمبر 2026 مقالة تحاجج بأن Git صُمم عام 2005 لسياق مختلف، حين كان المشروع الكبير يقاس بملايين الأسطر. أما اليوم فهناك شركات تعمل على مليارات الأسطر، وagents تكتب الكود أسرع من أي فريق بشري.

وترى المقالة أن المشكلة ليست في أوامر Git، بل في محرك التخزين الذي يعمل تحتها.

فـ Git مبني على افتراض أن كل مطور يحتفظ بنسخة كاملة من التاريخ كله على جهازه. وكان هذا الافتراض منطقيًا في وقته. لكن حين يكبر المستودع إلى مليارات الأسطر، وحين تُفتح عشرات الفروع في الوقت نفسه لأن كل agent يعمل على فرع خاص به، يتحول الافتراض إلى تكلفة: نسخ أبطأ، وطابور merge أطول.

ولا تقترح المقالة استبدال Git. فالفكرة أن يبقى الـ Git protocol كما هو، ويوضع تحته محرك تخزين مختلف، مع bridge يترجم بين الاثنين. وبهذا لا يلاحظ المستخدم أي تغيير، ولا يحتاج أحد إلى تعلم أوامر جديدة. ثم يُفتح المجال لاحقًا أمام protocols أخرى مثل Jujutsu. وتستند الفكرة إلى سابقة معروفة، هي نظام Google الداخلي لتخزين مليارات الأسطر في مستودع واحد.

لكن الناشر شركة تبيع هذا الحل تحديدًا. فللحجة مصلحة واضحة، والأرقام الواردة فيها ليست قياسًا محايدًا.

ومع ذلك، فجزء من المشكلة لا يحتاج إلى إعلان لإثباته. فالفرق التي تشغّل أكثر من agent على المستودع نفسه تواجه تزاحم الـ merge بشكل مباشر. والأدوات التي تعمل فوق Git تغيرت جذريًا خلال سنتين، بينما الطبقة التي تحتها عمرها عشرون عامًا. وعدد الفروع المفتوحة التي تنتجها الـ agents في مستودع ما قد يكون المؤشر الأوضح على مدى قرب هذه المشكلة منه.

## المصادر

- [المقالة على مدونة ERSC](https://ersc.io/blog/what-comes-after-git)
- [Jujutsu، نظام التحكم في الإصدارات](https://jj-vcs.github.io/jj/latest/)
- [بحث Google عن تخزين مليارات الأسطر في مستودع واحد](https://research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/)