‏گیت‌هاب بعدی، ارزش رقابت رو نداره

تو کمتر از سه هفته، گیت‌هاب سه‌بار قطعی جدی داشته: ۶ اوت ناوگان Actions به‌مدت ۹ ساعت مختل شد و ۷۱ درصد اجراها با خطای زیرساخت شکست خوردن، ۱۱ اوت API گرافیک‌کیوال (GraphQL) دو ساعت timeout می‌داد، و ۱۷ اوت کل سرویس -از وب و API گرفته تا Actions، Webhooks، Issues، Pull Requests و Copilot- هم‌زمان با نرخ خطای حدود ۲۰ درصد از کار افتاد. نویسنده می‌گه این یه اتفاق تک نیست بلکه یه الگوئه: بین ۱ تا ۱۸ اوت، خود گیت‌هاب ۱۷ حادثهٔ جدا ثبت کرده.

به گفتهٔ نویسنده، دو چیز پشت این وضعیته. اول، وابستگی عمیق بخش‌ها به هم: همون یکپارچگی‌ای که Actions رو کاربردی می‌کنه، باعث می‌شه وقتی API قطع می‌شه، Actions هم باهاش قطع بشه. دوم، تغییر شکل بار کاری؛ طبق آمار Octoverse گیت‌هاب، الان ۶۳۰ میلیون مخزن (repository) داره، هر دقیقه ۲۳۰ تا مخزن جدید ساخته می‌شه و ماهی ۴۳.۲ میلیون pull request مرج می‌شه، با رشد سالی ۲۳ درصد. گیت‌هاب تو گزارش خودش سیل مشارکت‌های کم‌کیفیت با هوش مصنوعی رو «حملهٔ denial-of-service به توجه آدم‌ها» توصیف کرده.

شرکت‌های بزرگ دارن سرمایه‌گذاری سنگین می‌کنن تا از این مشکل رد شن. Cursor -که به‌تازگی با ۶۰ میلیارد دلار توسط SpaceX خریداری شده- معماری Continuity رو منتشر کرده: ذخیره‌سازی آبجکتی به‌عنوان منبع اصلی، NVMe محلی به‌عنوان کش گرم، و هش رندوو (rendezvous hashing) که هر سروری بتونه نقش اصلی رو بگیره؛ این سیستم ثانیه‌ای ۱۲۰ تا ۳۰۰ push رو تحمل می‌کنه. توماس دومکه، مدیرعامل سابق گیت‌هاب، هم ۶۰ میلیون دلار برای استارتاپ Entire جذب کرده که مخزن‌ها رو تو یه شبکهٔ توزیع‌شده آینه‌سازی می‌کنه.

اما نویسنده معتقده سوال اصلی جای دیگه‌ست: چقدر از این حجم کد اصلاً لازم بود جایی فرستاده بشه؟ به گفتهٔ اون، خود git از سال ۲۰۰۵ کاملاً محلیه -کامیت، برنچ، دیف، ریبیس، هیچ‌کدوم به شبکه نیاز ندارن- و این لایهٔ اطراف git (ریویو، CI، ایشوها) هست که به سرور وصله. تو یه جلسهٔ کاری امروزی، ممکنه پنج ایجنت هم‌زمان پنج ورک‌تری (worktree) جدا باز کنن که چهارتاشون تا ظهر دور ریخته می‌شن؛ ولی همین‌الان هرکدوم یه برنچ ریموت، چند اجرای CI و کلی API call می‌گیرن، برای کاری که کل عمرش ۹۰ دقیقه رو یه ماشینه.

پیشنهاد نویسنده جایگزین کردن گیت‌هاب نیست، بلکه یه «منطقهٔ آماده‌سازی» محلیه: آزمایش کردن رو سیستم خودت، ارزون و سریع، و فقط وقتی چیزی واقعاً به‌درد خورد، push کردنش. برای نشون‌دادن این ایده، خودش ابزاری به اسم git-sprout نوشته: جایگزینی برای git worktree add که به‌جای کپی کامل پوشهٔ کاری، از قابلیت copy-on-write فایل‌سیستم استفاده می‌کنه. رو یه مخزن به‌اندازهٔ کرنل لینوکس، دستور معمولی ۱۸۱۶ مگابایت می‌نویسه، ولی git-sprout همون نتیجه رو با ۳۶ مگابایت می‌سازه:

brew install alltuner/tap/git-sprout
git sprout add ../myrepo-feature -b feature

نویسنده می‌گه این الگو قابل تعمیمه: یه پیشرفت کوچیک و محلی، ارزون‌تر از رقابت میلیارددلاری روی هاست بعدیه. آخر مقاله هم اشاره می‌کنه که تو همون هفتهٔ قطعی گیت‌هاب، چند مدل متن‌باز قدرتمند مثل GLM-5، DeepSeek V4 Pro، Qwen3.8-27B و Kimi K3 منتشر شدن؛ Qwen3.8-27B مثلاً با ۲۷ میلیارد پارامتر و مصرف حافظهٔ حدود ۱۸ گیگابایت، رو لپ‌تاپ جا می‌شه. به گفتهٔ نویسنده، این یعنی شاید به‌زودی کل چرخه -مخزن، ورک‌تری، فورج، CI و حتی مدل- بتونه رو یه دستگاه اجرا بشه، بدون اینکه هیچ‌جا وصل بشه.

نکات کلیدی:

• ۶، ۱۱ و ۱۷ اوت گیت‌هاب سه قطعی جدی داشته؛ تو قطعی ۱۷ اوت، Actions و Copilot و API هم‌زمان از کار افتادن
• بین ۱ تا ۱۸ اوت، گیت‌هاب ۱۷ حادثهٔ جدا ثبت کرده
• گیت‌هاب الان ۶۳۰ میلیون مخزن داره و ماهی ۴۳.۲ میلیون pull request مرج می‌کنه
• Cursor با ۶۰ میلیارد دلار به SpaceX فروخته شده و معماری Continuity رو برای مقیاس بالاتر git ساخته
• ابزار متن‌باز git-sprout نویسنده، حجم نوشتاری worktree رو از ۱۸۱۶ مگابایت به ۳۶ مگابایت می‌رسونه