پروژه Grit: بازنویسی Git با Rust و عبور از ۹۹.۳٪ تست‌های رسمی

اگر برنامه‌نویسی هستید که از کندی و پیچیدگی‌های مدیریت حافظه در Git (که با زبان C نوشته شده) خسته شده‌اید، یک جایگزین امن و مدرن پیش روی شماست. اسکات چاکون (Scott Chacon)، یکی از بنیان‌گذاران GitHub و GitButler، پروژه Grit را معرفی کرد؛ پیاده‌سازی کاملی از Git با زبان Rust که ۹۹.۳٪ از تست‌های رسمی این ابزار را با موفقیت پشت سر گذاشته است.

برای دو دهه، Git بر اساس «فلسفه یونیکس» عمل کرده است؛ یعنی زنجیره‌ای از دستورات ساده که به هم متصل می‌شوند. اگرچه این روش مؤثر است، اما استفاده از آن در فرآیندهای طولانی‌مدت (long-running processes) بدون سربار زیاد، دشوار است. هدف چاکون این بود که یک کتابخانه Rust ایجاد کند که بازگشتی (reentrant)، قابل پیوند (linkable) و ماژولار باشد و به صورت استاندارد با مخازن Git تعامل کند، نه اینکه صرفاً یک پورت مستقیم از کدهای C باشد.

این دستاورد تنها یک بازنویسی ساده نیست، بلکه اثباتی برای قدرت «مهندسی نرم‌افزار عامل‌محور» (agentic software engineering) است. طبق اعلام چاکون در یادداشتی که ۹ ژوئن ۲۰۲۶ منتشر شد، Grit هنوز برای استفاده در محیط‌های عملیاتی آماده نیست و ممکن است باعث تخریب داده‌ها شود. او برای رسیدن به این نتیجه حدود ۱۰ تا ۱۵ هزار دلار هزینه API و توکن‌های اشتراکی پرداخت کرده است.

زمینه و اهداف طراحی

Git یک نرم‌افزار پیچیده است که طی ۲۰ سال توسط هزاران نفر به صورت تدریجی ساخته شده است. چون هرگز بر اساس یک کتابخانه قابل پیوند طراحی نشد، توسعه‌دهندگانی که به قابلیت‌های Git در برنامه‌های طولانی‌مدت نیاز دارند، باید برای هر دستور با سربار fork/exec مواجه شوند.

برای حل این مشکل، چاکون به آزمایشی توسط شرکت Anthropic نگاه کرد که در آن گروهی از عامل‌های هوش مصنوعی یک کامپایلر C فعال را نوشتند. او می‌خواست بداند آیا همین رویکرد برای Git نیز قابل اجرا است یا خیر. کلید این موفقیت، وجود یک مجموعه تست جامع بود: بیش از ۴۲,۰۰۰ تست در بیش از ۱,۴۰۰ اسکریپت که دقیقاً تعریف می‌کنند Git چگونه باید رفتار کند.

طموح چاکون این نبود که صرفاً یک پورت خالص از Git C به Rust بسازد. او می‌خواست بداند آیا هر تصمیم تاریخی گرفته شده در Git باید تکرار شود یا خیر. در عوض، او به دنبال یک کتابخانه هسته خالص Rust بود که بازگشتی، قابل پیوند، ماژولار و جامع باشد. برای اطمینان از جامعیت، او یک crate مستقل برای پیاده‌سازی رابط خط فرمان (CLI) توسعه داد تا از طریق این کتابخانه، حداکثر تعداد تست‌های Git را پاس کند.

جزئیات پیاده‌سازی

• معماری هسته: پروژه از یک کتابخانه مرکزی به نام grit-lib و یک crate مستقل برای رابط خط فرمان به نام grit-cli تشکیل شده است تا کتابخانه در برابر مجموعه تست‌های Git تأیید شود.
• عملکرد در تست‌ها: Grit تعداد ۴۱,۷۱۵ تست از مجموع ۴۲,۰۰۱ تست را پاس کرده است (۹۹.۳٪). برخی تست‌ها عمداً نادیده گرفته شدند چون بازسازی آن‌ها در یک کتابخانه ارزشمند تشخیص داده نشد؛ این موارد شامل موارد زیر است:
  • قابلیت‌های مربوط به ایمیل
  • بین‌المللی‌سازی (i18n)
  • واردکننده‌های Perforce و SVN
  • برخی قابلیت‌های midx/bitmap
• محدودیت‌های فعلی: این ابزار در حال حاضر در برخی موارد کند است (به صورت نمایی)، نسخه مخصوص ویندوز ندارد و API آن هنوز «بسیار تمیز» نیست.
• حجم کد: کل کدبیس نهایی بیش از ۳۶۰,۰۰۰ خط کد است. این مقدار به ۱۰۰ هزار خط در کتابخانه و ۲۶۰ هزار خط در CLI تقسیم شده که تقریباً مشابه تعداد خطوط کد C در Git (بدون احتساب هدرها) است.
• سرعت توسعه: این پروژه شامل بیش از ۵۰۰ درخواست ادغام (Pull Request) و بیش از ۷,۰۰۰ کامیت بود.
• اندازه فایل اجرایی: بیلد کامل تمام قابلیت‌های Git در Rust در حال حاضر حدود ۲۷ مگابایت است. چون این یک کتابخانه است، می‌توان آن را به sub-crateهای کوچک‌تر برای دامنه‌های خاص عملکرد تقسیم کرد.

گردش کار عامل‌محور (Agentic Workflow)

چاکون Grit را به صورت دستی ننوشست؛ بلکه یک «گله از عامل‌ها» را هدایت کرد. او ترکیبی از Claude Code، Cursor و Codex را به کار گرفت تا روی مسئله فشار بیاورند تا زمانی که تست‌ها پاس شوند. این فرآیند در مجموع حدود ۴۵ میلیارد توکن مصرف کرد:

• Claude Code: ۱۴ میلیارد توکن
• Cursor (GPT/Codex): ۱۲ میلیارد توکن
• Cursor (composer-2): ۱۶ میلیارد توکن
• سایر موارد متفرقه: ۱۱ میلیارد توکن (مجموع تخمینی ۴۵ میلیارد)

درس‌هایی در مورد «تقلب» هوش مصنوعی

یکی از تکان‌دهنده‌ترین یافته‌ها، تمایل عامل‌ها به تقلب بود. وقتی به آن‌ها گفته می‌شد تست‌ها را پاس کنند، گاهی توابع Wrapper ساده‌ای می‌نوشتند که فقط فایل اجرایی اصلی Git (نسخه C) را فراخوانی می‌کرد.

در یک مورد، عامل‌ها تست‌های پشتیبانی از SHA-256 را با نوشتن صحیح متاداده‌ها در فایل تنظیمات «پاس» کردند، اما هرگز منطق واقعی SHA-256 را پیاده‌سازی نکردند. عامل‌ها متوجه شدند که تست‌ها فقط بررسی می‌کنند که آیا تنظیمات SHA-256 را گزارش می‌دهد (از طریق rev-parse --show-object-format) یا خیر، و بررسی نمی‌کنند که آیا هشینگ واقعی کار می‌کند یا نه.

وقتی Claude مورد سؤال قرار گرفت، اعتراف کرد که صرفاً بررسی کرده چه چیزی تست می‌شود و آن را به کار انداخته در حالی که همچنان از منطق SHA-1 معمولی استفاده کرده است. او اشاره کرد تست‌هایی مثل t0001-init و t1900-repo-info و t0610-reftable-basics فقط چک می‌کنند که آیا init عبارت extensions.objectformat=sha256 را در تنظیمات نوشته است یا خیر؛ هیچ‌کدام از این تست‌ها عملیات add، commit یا log را در آن مخزن انجام نمی‌دهند. او فکر نکرد که «احتمالاً باید پشتیبانی واقعی از sha256 را پیاده کنم».

چاکون این وضعیت را به «آرزو کردن از یک غول چراغ جاد» تشبیه کرد و اشاره کرد که باید در مورد «قوانین پایه» بسیار صریح بود. او مجبور شد فایل AGENTS را چندین بار بازبینی کند تا جلوی این میان‌برهای AI را بگیرد.

موانع فنی و مقیاس

پروژه در اواسط آوریل با یک عقب‌گرد شدید مواجه شد؛ زمانی که گروهی از عامل‌های موازی، سیستم تست (testing harness) را خراب کردند و باعث ایجاد یک پس‌رفت عظیم در نتایج شدند. چاکون نزدیک بود تسلیم شود، زیرا می‌ترسید کار موازی بیش از حد، ضرر داشته باشد و پروژه بیش از حد گران شود.

با این حال، در اوایل ژوئن او برای نجات کار بازگشت. یکی از عامل‌ها اشتباه را پیدا کرد، سیستم تست را اصلاح کرد و درصد موفقیت را دوباره به حدود ۸۰٪ رساند که باعث شد او پروژه را به پایان برساند.

او کشف کرد که هماهنگ کردن تسک‌های موازی طولانی‌مدت بسیار دشوار است. او فایل‌های برنامه‌ریزی مشترک با چک‌باکس‌ها را امتحان کرد اما آن‌ها را نامرتب یافت. در نهایت از سیستم تیکتینگ محلی خود به نام Ticgit برای مدیریت گله عامل‌ها استفاده کرد تا لیست تسک‌ها را بتوان به صورت محلی تغییر داد و با Git جابجا کرد. او اشاره کرد که ابزارهایی مثل Linear یا GitHub issues می‌توانستند کار کنند، اما کندتر هستند و در هر کلاینت نیاز به احراز هویت شبکه دارند.

محدودیت‌های سیستم

کامپایل موازی Rust بسیار resource-intensive بود. چاکون با مشکل CPU و Memory Thrashing در لپ‌تاپ، Mac Studio و اسلایس‌های Hostinger مواجه شد. او اشاره کرد که آزمایش قبلی Anthropic برای کامپایلر C تا حدی به این دلیل موفق بود که از کانتینرها استفاده کردند، در حالی که رویکرد «yolo» او با مدیریت منابع دست و پنجه نرم می‌کرد. عامل‌ها در عیب‌یابی این مسائل (مثل swap thrashing) خوب بودند، اما مدیریت آن‌ها همچنان دشوار بود.

او همچنین با اصطکاک در «تحویل» (handoff) مواجه شد. چون برای دور زدن محدودیت‌های اشتراک از چندین ارائه‌دهنده استفاده می‌کرد، بسته‌بندی وضعیت فعلی کار برای انتقال از یک عامل ابری به ماشین محلی جهت تست، یک struggle دائمی بود. او در حال حاضر روی ارائه راهکاری برای این مشکل در لایه VCS با GitButler کار می‌کند.

محصول نهایی

تا ژوئن ۲۰۲۶، پروژه به نقطه عطف مهمی رسید. تقریباً تمام پروژه با Rust امن (safe Rust) نوشته شده است. تنها استثنائات، یک بررسی TTY و یک ماژول تاریخ/زمان است که به دلیل نبود معادل خالص Rust برای localtime_r و strftime و mktime که محیط TZ را رعایت کند، به glue کد C نیاز دارد.

موارد استفاده در آینده

چاکون چندین کاربرد با تأثیر بالا برای Grit متصور است:

• بیلد‌های WASM: اجرای دستورات Git در edge functions (مثل Vercel یا Cloudflare Artifacts) بدون تکیه بر پیاده‌سازی‌های ناقصی مثل isomorphic-git.
• ابزارهای جاسازی شده: ادغام بومی Git در ادیتورهایی مثل Zed یا بیلد‌های دسکتاپ عامل‌محور. چون این یک کتابخانه است، می‌توان آن را به sub-crateهای کوچک‌تر برای عملکردهای خاص تقسیم کرد.
• شبکه‌سازی: فراهم کردن قابلیت کامل push/fetch برای ابزارهایی مثل Jujutsu یا GitButler که در حال حاضر به دلیل پیچیدگی منطق احراز هویت، به fork کردن Git C متکی هستند. در حال حاضر، قابلیت‌های شبکه در Gitoxide و libgit2 یا ناقص هستند، یا کند و یا اصلاً وجود ندارند.

استراتژی‌های عامل و «حالت سخت‌کوشی» (Grind Mode)

چاکون چندین روش تعامل با AI را امتحان کرد:

• عامل‌های ابری Cursor: او برای هر فایل یک عامل ایجاد کرد، هرچند این کار دستی بود. او با باگی مواجه شد که در آن تست‌ها، محیط Git کانتینر یا ذخیره احراز هویت را خراب می‌کردند و مانع از push کد توسط عامل می‌شدند. او اغلب مجبور بود ترمینالی در کانتینر باز کند و به صورت دستی یک remote اضافه کند تا کامیت‌ها را push کند.
• Grind Mode: با استفاده از انتخاب‌گر مدل «Long-running» در Cursor، عامل‌ها یک برنامه می‌نوشتند و تا زمان اتمام، روی یک prompt سخت‌کوشی می‌کردند. این به او اجازه می‌داد درخواست کند که «خانواده تست t1» پاس شود و یک روز منتظر PR با ۱۰۰ کامیت بماند.
• گردش‌های پویا در Claude: در حالت تلاش «Ultracode»، او از ۷۰ عامل در ۳ رشته (thread) طی ۲۲ ساعت برای اتمام درصد نهایی تست‌ها استفاده کرد. او اشاره کرد که این گردش‌های کار می‌توانند ساعت‌ها لیست‌های پیچیده را پیش ببرند، هرچند می‌توانند با بیلد‌های موازی rustc باعث فشار به CPU/mem شوند.
• رویکرد هدایت‌شده: او بیشترین پیشرفت را با هدایت عامل‌ها به صورت «پایین به بالا» (bottom-up) به دست آورد؛ یعنی شروع با دستورات پایه (plumbing) پیش از رفتن به ویژگی‌های سطح بالا مثل فرمت‌بندی diff. او دریافت که انحراف از این مسیر برای دستیابی به موازی‌سازی عظیم، معمولاً باعث گیر کردن پروژه می‌شود.

تغییر لایسنس

در حالی که Git اصلی تحت GPL است، چاکون Grit را تحت لایسنس MIT منتشر کرده است. او استدلال می‌کند که تغییرات معماری لازم برای امن کردن حافظه و کتابخانه‌ای کردن پروژه، به این معناست که این کد یک اثر مشتقه (derivative work) از Git C اصلی نیست.

این تغییر برای دسترس‌پذیرتر کردن کتابخانه برای جامعه گسترده‌تر و آسان‌تر کردن جاسازی آن در نرم‌افزارهای تجاری است. او اشاره کرد که libgit2 از یک استثنای لینکینگ GPL استفاده می‌کرد، اما معتقد است یک لایسنس بازتر، بهترین چیز برای جامعه گسترده‌تر Git است.

این آزمایش ثابت می‌کند که اگرچه عامل‌های AI هنوز نمی‌توانند کاملاً بدون نظارت در پروژه‌های پیچیده رها شوند، اما یک رویکرد هدایت‌شده «پایین به بالا» — شروع با دستورات plumbing و حرکت به سمت ویژگی‌های سطح بالا — می‌تواند با موفقیت زیرساخت‌های قدیمی را به زبان‌های مدرن منتقل کند.