gitai کے ساتھ AI ایجنٹس کے لیے موزوں ورژن کنٹرول سرور بنائیں

gitai کیا ہے؟

gitai ایک اوپن سورس ورژن کنٹرول سسٹم ہے جو AI کوڈنگ ایجنٹس کے لیے تیار کیا گیا ہے۔ یہ سرور پر مرکوز طریقہ اختیار کرتا ہے، جس میں کلائنٹس آن لائن رہتے ہیں، صرف مطلوبہ آبجیکٹس اور پاتھز حاصل کرتے ہیں، اور سورس کنٹرول آپریشنز سرور کو بھیجتے ہیں۔

یہ منصوبہ Anthropic کے عوامی طور پر بیان کردہ Scion ڈیزائن سے متاثر ہے، لیکن gitai ایک آزاد implementation ہے۔ یہ MIT لائسنس کے تحت ہے، کسی مخصوص وینڈر کا پابند نہیں، اور سرور کو لینگویج ماڈل کال کرنے کی ضرورت نہیں ہوتی۔ AI سے چلنے والے آپریشنز کسی بھی فراہم کنندہ، deterministic ٹول، یا کسی بھی AI فراہم کنندہ کے بغیر انجام دیے جا سکتے ہیں۔

اندرونی طور پر، gitai عام Git repositories استعمال کرتا ہے، جبکہ history queries، landing، changeset tracking، اور repository coordination کو سرور پر منتقل کرتا ہے۔ یہ ماڈل ایسے workloads کے لیے بنایا گیا ہے جن میں بہت سے مختصر مدتی کام مشترکہ branches پر تیزی سے تبدیلیاں شامل کرنا چاہتے ہیں۔

اہم خصوصیات

• منتخب ڈیٹا رسائی: آبجیکٹ سروس انفرادی آبجیکٹس اور sparse trees فراہم کرتی ہے۔ graft clone اور graft sparse کمانڈز صرف مطلوبہ پاتھز کو materialize کرتی ہیں۔
• سرور پر history: blame، path history، ancestry، اور code search سرور پر چلتے ہیں اور derived data کے طور پر memoize کیے جاتے ہیں۔
• بیک وقت landing: UserLand تبدیلیوں کو موجودہ branch tip پر rebase کرتا ہے اور روایتی merge queue کے بجائے compare-and-swap updates استعمال کرتا ہے۔ بیک وقت ہونے والی land کارروائیوں کو ایک reference update میں batch کیا جا سکتا ہے۔
• تنازع کا حل: متنازع land کارروائیاں versioned، vendor-neutral protocol کے ذریعے منتخب resolver استعمال کر سکتی ہیں۔
• Changeset log: منظور شدہ reference updates اپنے operation اور actor کو ایک مرتب log میں ریکارڈ کرتی ہیں، جسے کلائنٹس list یا watch کر سکتے ہیں۔
• قابل توسیع storage: SQLite یا PostgreSQL changesets، references، reviews، اور write-ahead log محفوظ کرتے ہیں، جبکہ content-addressed packs فائل storage، S3، GCS، یا Azure میں رکھے جا سکتے ہیں۔
• ایجنٹ کنٹرولز: فی ایجنٹ tokens، RPC allowlists، اور branch policies طے کرتی ہیں کہ ایجنٹس کون سے operations انجام دے سکتے ہیں۔
• تصدیق اور نگرانی: graft-verify tip کو test کر سکتا ہے، ناکامی پر bisect کر سکتا ہے، اور ذمہ دار تبدیلی واپس کر سکتا ہے۔ نگرانی کرنے والے ایجنٹس، جنہیں superfans کہا جاتا ہے، changeset stream کی پیروی کر سکتے ہیں اور Slack کے ذریعے رپورٹ کر سکتے ہیں۔
• سخت caching: graft-cache ہر آبجیکٹ کی تصدیق کرتے ہوئے immutable objects کو daemon اور علاقائی tiers میں cache کر سکتا ہے۔

architecture کیسے کام کرتی ہے

ایجنٹس، CI jobs، اور sparse workspaces Graft CLI یا Go SDK کے ذریعے gRPC پر gitai server سے رابطہ کرتے ہیں۔ اضافی cache tiers فراہم کرنے کے لیے ایک اختیاری graft-cache daemon سرور کے سامنے رکھا جا سکتا ہے۔

سرور landing، object access، changesets، derived data، search، اور review سنبھالتا ہے۔ اس کا write path ہر reference کے لیے ایک changeset کو compare-and-swap operation کے ساتھ جوڑتا ہے۔ Database storage changeset write-ahead log، references، changelog، اور reviews رکھتی ہے۔ Object storage content-addressed packs رکھتی ہے۔

Server nodes کو stateless caches کے طور پر ڈیزائن کیا گیا ہے جنہیں دوبارہ بنایا جا سکتا ہے۔ اس سے deployment بڑھنے کے ساتھ اضافی nodes شامل کیے جا سکتے ہیں۔ Local Git repositories caches کے طور پر دستیاب رہتی ہیں جنہیں کوئی بھی node دوبارہ بنا سکتا ہے۔

مزید تفصیل کے لیے منصوبے کی architecture documentation اور storage documentation پڑھیں۔

gitai انسٹال اور build کریں

1. ضروری prerequisites انسٹال کریں

gitai کے لیے فی الحال Linux یا macOS، Go 1.26، C toolchain، Meson، اور Ninja درکار ہیں۔ build میں Git کا bundled ورژن compile ہوتا ہے، اس لیے شروع کرنے سے پہلے یقینی بنائیں کہ مطلوبہ native build tools دستیاب ہیں۔

2. repository clone کریں

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

3. binaries build کریں

سرور، CLI، اور معاون tools build کرنے کے لیے Make target چلائیں:

make build

نتیجے میں بننے والی binaries _build/bin میں رکھی جاتی ہیں۔ CLI اور اس کی دستیاب کمانڈز دیکھنے کے لیے چلائیں:

./_build/bin/graft

quickstart چلائیں

repository میں ایک مثال شامل ہے جو server، cache daemon، دو agents، اور ایک land operation کے ساتھ عارضی gitai environment شروع کرتی ہے:

examples/graft/quickstart.sh

مستقل database، object store، یا deployment تیار کیے بغیر بنیادی workflow دیکھنے کا یہ تیز ترین طریقہ ہے۔ چونکہ مثال عارضی directory استعمال کرتی ہے، اس لیے یہ سیکھنے اور تجربہ کرنے کے لیے زیادہ موزوں ہے۔

اپنا server چلائیں

1. مثال کی configuration سے شروع کریں

custom server configuration کے لیے examples/graft/config.toml کو ابتدائی نقطۂ آغاز کے طور پر استعمال کریں۔ بنائی گئی binary کے ذریعے سرور شروع کیا جا سکتا ہے:

_build/bin/gitaly serve config.toml

source tree کے اندر سرور سائیڈ extensions کو Graft کہا جاتا ہے۔ آپ کو یہ نام [graft] configuration section، graft CLI، internal/graft package، اور Graft documentation میں نظر آئے گا۔

2. database اور object storage شامل کریں

ایسی deployment کے لیے جس میں repository state database اور object storage میں محفوظ ہو، configuration میں [graft.storage] section شامل کریں۔ دستاویزی migration process یہ ہے کہ shadow mode میں شروع کریں، repositories import کریں، اور پھر authoritative mode پر منتقل ہو جائیں۔

درست configuration اور migration details کے لیے storage guide پر عمل کریں۔ معاون storage model coordination data کے لیے SQLite یا PostgreSQL، اور content-addressed packs کے لیے file، S3، GCS، یا Azure storage استعمال کرتا ہے۔

agent تبدیلیوں کے ساتھ کام کریں

روایتی Git ورک فلو میں ہر کارکن ایک ریپوزٹری کلون کر سکتا ہے، مقامی طور پر ڈیولپ کر سکتا ہے، اور مشترکہ برانچ پر پُش کر سکتا ہے۔ gitai اس کے بجائے ایجنٹس کو سرور سے منسلک رہنے اور صرف مطلوبہ ڈیٹا کی درخواست کرنے کی سہولت دیتا ہے۔

ایجنٹس مٹیریلائز کیے گئے راستوں کو محدود کرنے کے لیے sparse ورک اسپیسز استعمال کر سکتے ہیں۔ متعلقہ کمانڈز میں شامل ہیں:

• graft clone ریپوزٹری کا منتخب ویو مٹیریلائز کرنے کے لیے۔
• graft sparse کسی کام کے لیے درکار راستوں کی درخواست یا صرف ان میں ترمیم کرنے کے لیے۔

جب کوئی ایجنٹ تعاون کے لیے تیار ہو، تو UserLand تبدیلی کو موجودہ ٹِپ پر ری بیس کرتا ہے اور compare-and-swap اپ ڈیٹ کی کوشش کرتا ہے۔ اگر ایک برانچ پر متعدد ایجنٹس بیک وقت تبدیلیاں لینڈ کریں، تو gitai ہر ایجنٹ کو الگ merge queue سے گزارنے کے بجائے ان آپریشنز کو ایک reference update میں بیچ کر سکتا ہے۔

اگر land کے نتیجے میں تنازع پیدا ہو، تو تنازع حل کرنے کی دستاویزات کے مطابق resolver ترتیب دیں۔ resolver کسی LLM provider، deterministic tool، یا کسی بیرونی AI provider کے بغیر بھی مبنی ہو سکتا ہے۔

changesets، reviews، اور verification کا جائزہ لیں

Changeset history

ہر منظور شدہ reference update changeset log میں ایک اندراج بن جاتا ہے۔ اندراج میں آپریشن اور actor شامل ہوتے ہیں، جس سے کلائنٹس کو ایک مرتب ریکارڈ ملتا ہے جسے وہ فہرست کی صورت میں دیکھ سکتے ہیں یا لائیو مانیٹر کر سکتے ہیں۔ یہ stream ان monitoring agents کو بھی چلا سکتی ہے جو مخصوص components سے متعلق تبدیلیوں کا سراغ رکھتے ہیں۔

Reviews اور policies

gitai میں semantic approval rules کے ساتھ agent-friendly reviews شامل ہیں۔ مثال کے طور پر، صرف comment والی تبدیلی کے لیے logic کی تبدیلی کے مقابلے میں کم approvals درکار ہو سکتی ہیں۔ ایجنٹ سیکیورٹی کنٹرولز میں فی ایجنٹ tokens، RPC allowlists، اور branch policies بھی شامل ہیں۔

سرور کو خودکار صارفین کے لیے دستیاب کرنے سے پہلے review documentation اور agent security documentation پڑھیں۔

Landing کے بعد verification

graft-verify workflow تبدیلیاں land ہونے کے بعد برانچ ٹِپ کی جانچ کرتا ہے۔ اگر کوئی ٹیسٹ ناکام ہو جائے، تو یہ تبدیلیوں کو bisect کر کے اس تبدیلی کو revert کر سکتا ہے جس نے ناکامی متعارف کرائی۔ اس سے ایسا workflow ممکن ہوتا ہے جس میں integration مسلسل ہوتی رہتی ہے اور سسٹم خراب ٹِپ کے لیے ذمہ دار تبدیلی کی نشاندہی کرتا ہے۔

موزوں workflow اور configuration کے لیے verification guide دیکھیں۔

Advanced deployment tips

• Caching سوچ سمجھ کر استعمال کریں: جب ایجنٹس یا CI jobs کو daemon یا regional cache tiers میں immutable objects تک تیز رسائی درکار ہو، تو graft-cache شامل کریں۔
• Coordination کو object storage سے الگ رکھیں: changesets اور references کے لیے SQLite یا PostgreSQL استعمال کریں، اور repository packs کے لیے object-storage backend ترتیب دیں۔
• اضافی nodes کے ساتھ scale کریں: سرور nodes کو دوبارہ تعمیر کیے جا سکنے والے caches کے طور پر ڈیزائن کیا گیا ہے، اس لیے nodes شامل کرنے کے لیے ہر node پر الگ authoritative state رکھنا ضروری نہیں۔
• Landing documentation پڑھیں: landing and batching guide compare-and-swap workflow اور concurrent updates کی وضاحت کرتی ہے۔
• موجودہ limitations کا جائزہ لیں: یہ version 0.1.0 ہے، interfaces میں 1.0 سے پہلے تبدیلی آ سکتی ہے، اور packs کی garbage collection جیسے معلوم gaps LIMITATIONS.md میں درج ہیں۔
• Design documents استعمال کریں: PLAN.md سے PLAN6.md تک implementation کے جواز اور ارتقا کی وضاحت کرتے ہیں۔

نتیجہ

gitai بہت سے بیک وقت coding agents کے زیرِ استعمال ریپوزٹریز کے لیے server-centric source-control model کو ڈھالتا ہے۔ اس کا Graft CLI اور سرور sparse data access، server-side history، compare-and-swap landing، conflict resolution، changeset logs، reviews، verification، اور scalable storage فراہم کرتے ہیں۔

make build اور examples/graft/quickstart.sh سے آغاز کریں، پھر workflow سمجھ آنے پر configured server اور persistent storage کی طرف بڑھیں۔ مزید گہری implementation اور operational guidance کے لیے project کی Quickstart، configuration reference، اور architecture documentation استعمال کریں۔