بني خادم للتحكم فالإصدارات مناسب لوكلاء الذكاء الاصطناعي باستعمال gitai

شنو هو gitai؟

gitai هو نظام مفتوح المصدر للتحكم فالإصدارات، مصمم لوكلاء البرمجة بالذكاء الاصطناعي. كيطبق نهج متمحور حول الخادم، بحيث كيبقاو العملاء متصلين، كيجيبو غير الكائنات والمسارات اللي محتاجين، وكيرسلو عمليات التحكم فالمصدر للخادم.

المشروع مستوحى من التصميم الموصوف للعموم ديال Scion من Anthropic، ولكن gitai تطبيق مستقل. مرخص برخصة MIT، ومحايد تجاه المورّدين، وما كيحتاجش الخادم يستدعي نموذج لغوي. العمليات المدعومة بالذكاء الاصطناعي تقدر تستعمل أي مزوّد، أو أداة حتمية، أو حتى بلا أي مزوّد للذكاء الاصطناعي.

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

الميزات الرئيسية

• ولوج انتقائي للبيانات: خدمة الكائنات كتوفّر كائنات فردية وأشجار متفرقة. الأمران graft clone وgraft sparse كينشئو غير المسارات المطلوبة.
• تاريخ من جهة الخادم: أوامر blame، وتاريخ المسار، والأصل، والبحث فالكود كيتنفذوا فالخادم وكيتم حفظهم كبيانات مشتقة.
• إدماج متزامن: UserLand كيعيد تأسيس التغييرات فوق آخر نسخة من الفرع، وكيستعمل تحديثات compare-and-swap بلا طابور دمج تقليدي. عمليات الإدماج المتزامنة تقدر تتجمع فتحديث واحد للمرجع.
• حل التعارضات: عمليات الإدماج المتعارضة تقدر تستعمل محلّل مختار عبر بروتوكول محايد تجاه المورّدين ومُصدَر بإصدارات.
• سجل مجموعات التغييرات: تحديثات المراجع المقبولة كتسجل العملية والفاعل ديالها فسجل مرتب، اللي يقدرو العملاء يعرضوه أو يتابعوه.
• تخزين قابل للتوسّع: SQLite أو PostgreSQL كيخزنو مجموعات التغييرات، والمراجع، والمراجعات، وسجل الكتابة المسبقة، بينما الحزم المعنونة بالمحتوى تقدر تكون فتخزين الملفات أو S3 أو GCS أو Azure.
• ضوابط الوكلاء: الرموز الخاصة بكل وكيل، وقوائم RPC المسموح بها، وسياسات الفروع كتحدد العمليات اللي يقدرو الوكلاء يديروها.
• التحقق والمراقبة: graft-verify يقدر يختبر آخر نسخة، ويحدد موضع العطل بالـbisect، ويرجع التغيير المسؤول. وكلاء المراقبة، اللي كيتسمّاو superfans، كيتبعو تدفق مجموعات التغييرات ويقدرو يرسلو التقارير عبر Slack.
• التخزين المؤقت الصارم: graft-cache يقدر يخزن الكائنات غير القابلة للتغيير فطبقات خوادم محلية وجهوية، مع التحقق من كل كائن.

كيفاش كتخدم البنية

الوكلاء، ومهام CI، وبيئات العمل المتفرقة كيتواصلو مع خادم gitai عبر واجهة Graft CLI أو Go SDK باستعمال gRPC. وكيقدر daemon اختياري ديال graft-cache يكون قدّام الخادم باش يوفّر طبقات تخزين مؤقت إضافية.

الخادم كيتكلف بالإدماج، والولوج للكائنات، ومجموعات التغييرات، والبيانات المشتقة، والبحث، والمراجعة. مسار الكتابة ديالو كيجمع مجموعة تغييرات مع عملية compare-and-swap لكل مرجع. تخزين قاعدة البيانات كيحتافظ بسجل الكتابة المسبقة لمجموعات التغييرات، والمراجع، وسجل التغييرات، والمراجعات. تخزين الكائنات كيحتافظ بالحزم المعنونة بالمحتوى.

عُقد الخادم مصممة تكون مخازن مؤقتة بلا حالة ويمكن إعادة بنائها. هاد الشي كيخلي إضافة عُقد أخرى ممكنة مع توسّع النشر. مستودعات Git المحلية كتبقى متاحة كمخازن مؤقتة يقدر أي خادم يعاود يبنيها.

لمزيد من التفاصيل، قرا توثيق بنية المشروع وتوثيق التخزين.

تثبيت وبناء gitai

1. ثبّت المتطلبات المسبقة

gitai كيتطلب حاليا Linux أو macOS، وGo 1.26، وسلسلة أدوات C، وMeson، وNinja. البناء كيجمّع نسخة مرفقة من Git، لذلك تأكد من توفر أدوات البناء الأصلية المطلوبة قبل ما تبدا.

2. نسخ المستودع

git clone https://github.com/feder-cr/git-ai.git
cd git-ai

3. بناء الملفات التنفيذية

شغّل هدف Make باش تبني الخادم، وواجهة CLI، والأدوات المساعدة:

make build

الملفات التنفيذية الناتجة كتحط فـ_build/bin. باش تشوف واجهة CLI والأوامر المتاحة فيها، شغّل:

./_build/bin/graft

تشغيل البداية السريعة

المستودع فيه مثال كيشغّل بيئة gitai مؤقتة فيها خادم، وdaemon ديال التخزين المؤقت، وجوج وكلاء، وعملية إدماج:

examples/graft/quickstart.sh

هاد الطريقة هي الأسرع باش تشوف سير العمل الأساسي بلا ما تجهز قاعدة بيانات دائمة، أو مخزن كائنات، أو نشر. وحيت المثال كيستعمل مجلدا مؤقتا، فهو مناسب أكثر للتعلم والتجريب.

تشغيل الخادم ديالك

1. بدا بإعداد المثال

استعمل examples/graft/config.toml كنقطة انطلاق لإعداد خادم مخصص. يمكن تشغيل الخادم بالملف التنفيذي المبني:

_build/bin/gitaly serve config.toml

داخل شجرة المصدر، الامتدادات الخاصة بالخادم كتسمّى Graft. غتشوف هاد الاسم فقسم الإعداد [graft]، وواجهة CLI ديال graft، والحزمة internal/graft، وتوثيق Graft.

2. إضافة قاعدة البيانات وتخزين الكائنات

فالنشر اللي كتتخزن فيه حالة المستودع فقاعدة بيانات وتخزين الكائنات، زِد قسم [graft.storage] للإعداد. عملية الترحيل الموثقة هي تبدا بوضع shadow، وتستورد المستودعات، ومن بعد تبدّل لوضع authoritative.

تبع دليل التخزين باش تعرف تفاصيل الإعداد والترحيل بالضبط. نموذج التخزين المدعوم كيستعمل SQLite أو PostgreSQL لبيانات التنسيق، وتخزين الملفات أو S3 أو GCS أو Azure للحزم المعنونة بالمحتوى.

العمل مع تغييرات الوكلاء

فواحد الطريقة التقليدية ديال الخدمة بـ Git، كل واحد كيقدر يدير clone للمستودع، يطوّر محلياً، ويدفع التغييرات لفرع مشترك. gitai كيسمح بدال هاد الشي للـ agents يبقاو مربوطين بالسيرفر ويطلبو غير البيانات اللي محتاجين.

الـ agents يقدرو يستعملو workspaces ناقصة باش يحدّو من المسارات اللي كيتحضّرو فعلياً. الأوامر المهمة هي:

• graft clone باش تحضّر view مختارة من المستودع.
• graft sparse باش تطلب أو تبدّل غير المسارات اللي محتاجها التّاسك.

ملي كيكون agent واجد يساهم، UserLand كيدير rebase للتغيير فوق آخر tip وكيحاول يدير update بـ compare-and-swap. إلا هبطو بزاف ديال الـ agents تغييرات فالنفس الوقت ففرع واحد، gitai يقدر يجمع هاد العمليات فـ reference update واحد بلا ما يفرض على كل agent يدوز من merge queue بوحدو.

إلا نتج conflict فعملية الهبوط، كوّن resolver على حساب التوثيق ديال حلّ التعارضات. الـ resolver يقدر يعتمد على مزوّد LLM، أداة حتمية، أو بلا حتى مزوّد AI خارجي.

استكشف changesets وreviews وverification

تاريخ changesets

كل reference update مقبول كيولي مدخلة فـ changeset log. المدخلة فيها العملية والفاعل، وكتعطي للـ clients سجلاً مرتباً يقدرو يعرضوه أو يتبعوه مباشرة. هاد stream يقدر حتى يحرّك agents ديال المراقبة اللي كيتبعو التغييرات المرتابطة بمكوّنات معيّنة.

Reviews والسياسات

gitai فيه reviews مهيّأة للـ agents مع قواعد موافقة دلالية. مثلاً، تغيير فالتعليقات فقط يقدر يحتاج موافقات أقل من تغيير فالمنطق. ضوابط أمان الـ agents كتضم حتى tokens خاصّة بكل agent، وRPC allowlists، وسياسات الفروع.

قرا توثيق المراجعة وتوثيق أمان الـ agents قبل ما تعرّض السيرفر لمستخدمين آليين.

التحقق من بعد الهبوط

workflow ديال graft-verify كيختبر tip ديال الفرع من بعد ما كتهبط التغييرات. إلا فشل شي test، يقدر يدير bisect للتغييرات ويرجّع التغيير اللي سبّب الفشل. هاد الشي كيدعم workflow اللي فيه الاندماج كيدوز باستمرار والسيستم كيحدّد التغيير المسؤول على tip مكسور.

شوف دليل التحقق على الـ workflow والإعدادات المدعومة.

نصائح متقدمة للنشر

• استعمل caching بوعي: زِد graft-cache ملي كيحتاجو الـ agents أو CI jobs وصول سريع للـ immutable objects عبر طبقات cache ديال daemon أو المناطق.
• فرّق بين التنسيق وتخزين objects: استعمل SQLite أو PostgreSQL للـ changesets والـ references، وكوّن backend ديال object storage لحزم المستودعات.
• كبّر النظام بعُقد إضافية: عُقد السيرفر مصمّمة كـ caches قابلة لإعادة البناء، لذلك إضافة عُقد ما كتحتاجش كل عقدة تكون عندها حالة مستقلة ومرجعية.
• قرا توثيق الهبوط: دليل الهبوط وتجميع العمليات كيشرح workflow ديال compare-and-swap والتحديثات المتزامنة.
• راجع القيود الحالية: هادي هي النسخة 0.1.0، والواجهات تقدر تتبدّل قبل 1.0، والفجوات المعروفة بحال garbage collection ديال الحزم موثّقة فـ LIMITATIONS.md.
• استعمل وثائق التصميم: من PLAN.md حتى PLAN6.md كَيشرحو علاش وكيفاش تطوّر التنفيذ.

الخلاصة

gitai كيكيّف نموذج ديال source control متمحور حول السيرفر مع مستودعات كيخدمو عليها بزاف ديال coding agents فالنفس الوقت. الـ Graft CLI والسيرفر ديالو كيوفّرو ولوج ناقص للبيانات، وتاريخ على السيرفر، وهبوط بـ compare-and-swap، وحلّ التعارضات، وسجلات changesets، وreviews، وverification، وتخزين قابل للتوسّع.

بدا بـ make build وexamples/graft/quickstart.sh، ومن بعد دوز لسيرفر مكوّن وتخزين دائم ملي تفهم الـ workflow. ولمزيد من الإرشادات حول التنفيذ والتشغيل، استعمل Quickstart ديال المشروع، ومرجع الإعدادات، ووثائق المعمارية.