حدود دو سال از وقتی آندری کارپاتی عبارت وایبکدینگ (Vibe Coding) را برای ساختن نرمافزار با زبان طبیعی جا انداخت میگذرد. امروز بحث دیگر بر سر این نیست که مدل میتواند کد بنویسد یا نه؛ بحث بر سر این است که چطور این حجم از تغییر را وارد چرخهی نرمافزار کنیم بدون اینکه تاریخچهی پروژه به یک آشغالدانی از کامیتهای بیمعنی تبدیل شود.
در همین دو سال، ابزارها از «تکمیل خودکار کد» به عاملهای خودمختار (Autonomous Agents) رسیدند؛ عاملهایی که خودشان فایل میخوانند، تست اجرا میکنند، چند مرحله را پشت سر هم انجام میدهند و در نهایت باید جایی کارشان را تحویل بدهند. آن «جای تحویل»، تقریباً همیشه گیت است.
و دقیقاً همینجاست که یک تناقض قدیمی دوباره سر باز میکند: گیت برای انسانهایی طراحی شده که روزی چند بار کامیت میزنند، نه برای ناوگانی از عاملها که در چند دقیقه دهها فایل را تغییر میدهند. در این مطلب میبینیم چرا نسخهکنترل دوباره به گلوگاه تبدیل شده، شرکتهای بزرگ چه کاری کردهاند و نقش گیت در دورهی جدید چه میشود.
باری که یکشبه روی گیت افتاد
اعداد گیتهاب در سال ۲۰۲۶ بهخوبی نشان میدهند که چه اتفاقی افتاده است. در سپتامبر ۲۰۲۶، توسعهدهندهها و عاملها روی گیتهاب ۷.۳۸ میلیارد کامیت ثبت کردند؛ بیش از پنج برابر سال قبل. حجم کل فعالیت گیت در ماه از ۲۱۸.۲ میلیارد رویداد به ۴۷۳.۳ میلیارد رسید و تعداد پوشها ۴.۹ برابر شد.
این فقط یک رشد خطی نیست؛ تغییر جنس بار کاری است. یک انسان وقتی یک تغییر منطقی را تمام میکند کامیت میزند. یک عامل در حلقهی «فکر کن، ویرایش کن، تست کن» ممکن است بعد از هر قدم یک چکپوینت بسازد. نتیجه این است که دیگر نوشتن کد گلوگاه نیست؛ ثبت، بازبینی و ادغام تغییرات گلوگاه است.
گیتهاب در اکتبر ۲۰۲۶ اعلام کرد که زیرساخت گیت خود را در حالی که سرویس زنده است از نو میسازد. معماری قبلی برای خواندن خوب مقیاس میشد، اما هر نسخهی تکراری باید در هر نوشتن هم شرکت میکرد؛ یعنی اضافه کردن ظرفیت خواندن، نوشتن را کندتر میکرد. در معماری جدید، ذخیرهسازی از پردازش جدا شده و در بنچمارک داخلی تا ۳۵ برابر توان نوشتن بیشتر گزارش شده است.
این آمار یک پیام روشن دارد: عصر عاملها گیت را حذف نکرد؛ آن را به یکی از مهمترین زیرساختهای نرمافزار تبدیل کرد.
شرکتهایی که گیت به گلوگاهشان خورد
ماجرای «گیت برای این حجم ساخته نشده» تازه نیست. شرکتهای بزرگ سالها پیش به سقفهای گیت خوردهاند و هر کدام راهی رفتهاند. تفاوت این است که حالا عاملها همان فشار را به تیمهای معمولی هم آوردهاند.
متا: وقتی مونوریپو از گیت بزرگتر میشود
متا سالها با یک مونوریپوی غولپیکر دستوپنجه نرم کرد. طبق مستندات خودشان، مخزن اصلی این شرکت به دهها میلیون فایل، کامیت و شاخه میرسد و ابزارهای متنباز آن زمان برای این مقیاس کافی نبودند. به جای رها کردن مونوریپو، Sapling را ساختند: یک سیستم نسخهکنترل با رابط کاربری سادهتر، پشتیبانی از استک کامیتها و قابلیت بازگشت راحت، که در ابتدا بر پایهی Mercurial بود و بعداً پشتیبانی از مخازن گیت هم به آن اضافه شد.
درس متا این نبود که «گیت بد است»؛ این بود که لایهی تجربه و لایهی ذخیرهسازی را میتوان از هم جدا کرد. Sapling همان مخزن گیت را میخواند، اما workflow را برای مقیاس و انسانهای عادی بازطراحی میکند.
مایکروسافت: مخزنی با میلیونها فایل
مخزن ویندوز یکی از بزرگترین مخازن کد جهان است؛ میلیونها فایل و صدها گیگابایت داده. سالها کلون کردن کامل این مخزن ساعتها طول میکشید و حتی دستورهای ساده هم دردسر داشتند. مایکروسافت ابتدا GVFS را ساخت و بعد Scalar را؛ مجموعهای از تکنیکها مثل کلون جزئی (Partial Clone)، Sparse Checkout و FS Monitor.
نکتهی جالب این است که بخش بزرگی از این ایدهها وارد خود گیت شد. امروز خیلی از تیمها بدون اینکه بدانند از همان راهحلها استفاده میکنند؛ مثلاً وقتی با --filter=blob:none کلون میکنند یا فقط بخشی از درخت فایل را checkout میکنند.
گوگل: از Piper تا Jujutsu
گوگل هیچوقت برای مونوریپوی عظیمش به گیت تکیه نکرد؛ سیستم داخلی Piper را دارد. اما در سالهای اخیر Jujutsu (jj) را جدی گرفته و در ۲۰۲۶ آن را به دسترسی عمومی برای توسعهدهندههای داخلی گوگل رسانده است. jj روی همان object model گیت سوار میشود، اما چند چیز را عوض میکند:
- Change ID پایدار: یک تغییر بعد از rebase یا بازنویسی تاریخچه هم قابل ردیابی میماند.
- Undo در سطح operation: کل عملیات نسخهکنترل برگشتپذیر است، نه فقط آخرین کامیت.
- تعارض بهعنوان داده: تعارضها میتوانند ذخیره شوند و rebase بدون توقف وسط کار تمام شود.
گوگل برای مهاجرت به SHA-256 هم از ابزار Copybara برای پل زدن بین مخازن ناسازگار استفاده میکند. اینها همه نشانهی یک چیز است: حتی غولهایی که گیت را دوست دارند، مجبورند لایههای بالای آن را بازطراحی کنند.
گیتهاب: بازسازی زیرساخت در حال کار
خود گیتهاب هم به همین سقف خورده است. وقتی یک مخزن در ماه حدود یک میلیارد درخواست میگیرد و CI و اسکن امنیتی هر پوش را به هزاران خواندن تبدیل میکنند، معماری قدیمی جواب نمیدهد. به همین دلیل گیتهاب ذخیرهسازی را به Azure Blob منتقل کرده، maintenance را از مسیر سرویس بیرون برده و نوشتن را از خواندن جدا کرده است.
این تغییرها برای انسانها تقریباً نامرئیاند، اما برای عاملها حیاتی هستند: تأخیر یک پوش برای یک انسان قابل تحمل است؛ برای عاملی که در حلقهی tight-loop هر چند ثانیه چکپوینت میزند، همان تأخیر یعنی کندی کل سیستم.
استودیوهای بازی: هنوز هم Perforce
خارج از دنیای نرمافزار وب، خیلی از استودیوهای بازی هنوز Perforce را انتخاب میکنند. دلیلش ساده است: فایلهای باینری بزرگ، قفل فایل و نیاز به همکاری روی assetها. گیت برای فایلهای متنی و تاریخچهی خطی عالی است؛ برای فایلهای ۵ گیگابایتی نه. این یادآوری خوبی است که «نسخهکنترل» یک چیز واحد نیست.
مشکل فقط سرعت نیست؛ گیت منطق عامل را نمیفهمد
حتی اگر زیرساخت را بینهایت سریع کنیم، یک مشکل عمیقتر باقی میماند: گیت تغییرات را متنی مقایسه میکند، نه معنایی. اگر دو عامل یک تابع را از دو زاویهی متفاوت تغییر بدهند، ممکن است گیت بگوید «تعارضی نیست» و merge را انجام بدهد، اما رفتار برنامه خراب شود. این همان تعارض معنایی (Semantic Conflict) است که با بزرگتر شدن حجم تغییرات، بیشتر و بیشتر میشود.
مشکل دوم، نویز تاریخچه است. عاملها تمایل دارند بعد از هر قدم کامیت بزنند: «ویرایش فایل»، «تلاش دوم»، «رفع تست»، «تلاش سوم». در پروژهی Grit که اسکات چاکون با کمک عاملها گیت را به Rust بازنویسی کرد، حاصل کار بیش از ۷۰۰۰ کامیت و ۵۰۰ پولریکوئست بود. این حجم برای یک پروژهی چندماهه عجیب نیست، اما برای تیمی که میخواهد تاریخچه را مرور کند، فاجعه است.
مشکل سوم، اعتماد است. در همان پروژه Grit، وقتی به عامل گفتند «تستهای SHA-256 را پاس کن»، عامل بهجای پیادهسازی واقعی SHA-256 فقط کاری کرد که تستها سبز شوند؛ یعنی متادیتای فرمت را نوشت اما هیچ کامیت واقعی با SHA-256 انجام نشد. چاکون این را «عاملها عاشق تقلباند» توصیف میکند. عاملها همچنین نمیفهمند چه چیزی را شکستهاند؛ یک تغییر کوچک در یک فایل مشترک میتواند نیمی از تستها را خراب کند بدون اینکه عامل متوجه شود.
گیت به تو میگوید چه چیزی تغییر کرده؛ اما نمیگوید چرا تغییر کرده و آیا اصلاً باید تغییر میکرد. در عصر عاملها، همین «چرا» ارزشمندترین بخش است.
مشکل چهارم، خود رابط گیت است. دستورهایی مثل git rebase -i برای انسان طراحی شدهاند؛ برای یک LLM هم گراناند و هم خطاپذیر. بنچمارک خود GitButler روی ۳۰۰ اجرای کنترلشده نشان داد ابزار اختصاصیشان حدود ۶۰٪ سریعتر از گیت و با ۸۰٪ دستور کمتر کار را تمام میکند. البته این بنچمارک را خود شرکت سازنده گرفته و باید با احتیاط خواند، اما جهت را درست نشان میدهد: ابزارهای نسخهکنترل باید برای «مصرفکنندهی ماشینی» هم طراحی شوند.
و در نهایت، مشکل بازبینی. وقتی یک عامل میتواند در یک نشست صدها فایل را تغییر بدهد، بازبینی diff به یک کار طاقتفرسا تبدیل میشود. گیتهاب گزارش داده که برای اپ Copilot خود، سطح نمایش diff را از نو ساخته تا بتواند پولریکوئستهای میلیونخطی را با صدها کامنت باز کند. این یک دستاورد مهندسی است، اما همزمان هشداری است: اگر حجم تغییر از توان بازبینی انسان بیشتر شود، سرعت تولید کد به سرعت تولید بدهی فنی تبدیل میشود.
راهحلها: از worktree تا عاملهای امن
خوشبختانه، پاسخها لزوماً «گیت جدید» نیستند. بخش زیادی از راهحل، استفادهی درست از همان گیت است؛ بهعلاوهی ابزارهایی که روی آن ساخته شدهاند.
هر عامل، یک شاخه و یک worktree
اگر چند عامل را همزمان روی یک working tree اجرا کنی، تغییراتشان با هم قاطی میشود. راه ساده و قدرتمند گیت برای این کار worktree است: هر تسک شاخه و پوشهی مستقل خودش را میگیرد، اما همه از یک مخزن تغذیه میشوند.
git worktree add ../agent-login -b agent/login
cd ../agent-login
# عامل اینجا کار میکند
git add -p
git commit -m "feat(auth): add magic-link login"
git push -u origin agent/loginمزیت این کار فقط تمیزی نیست؛ blast radius را هم کوچک میکند. اگر عامل خرابکاری کرد، کل شاخه را دور میریزی و بقیه کارها دستنخورده میمانند.
jj: وقتی تاریخچه قابل بازنویسی است
Jujutsu برای تیمهایی جذاب است که با rebase و استک کردن تغییرات زیاد سروکار دارند. چون هر تغییر یک شناسهی پایدار دارد، لازم نیست نگران گم شدن کامیت بعد از بازنویسی باشی. عملیاتها قابل undo هستند و تعارضها بهجای متوقف کردن کار، بهعنوان داده ذخیره میشوند. گوگل همین حالا از آن استفاده میکند و جامعهی متنباز هم بهسرعت در حال رشد است.
GitButler: نسخهکنترل برای انسان و عامل
GitButler که توسط یکی از بنیانگذاران گیتهاب ساخته شده، روی همین ایده سرمایهگذاری کرده است. این شرکت در آوریل ۲۰۲۶ یک راند ۱۷ میلیون دلاری جذب کرد و صریحاً گفت که میخواهد «چیزی بعد از گیت» بسازد. ابزار آنها با شاخههای مجازی، استک کردن تغییرات، undo و یک CLI به نام but سعی میکند همان کاری را برای عاملها انجام بدهد که گیت برای انسانها کرد: یک لایهی امن برای آزمایش، بازبینی و برگشت.
جملهی کلیدی مدیرعامل آنها این است: «ما داریم به ناوگانهایی از عاملها ابزاری را یاد میدهیم که برای فرستادن پچ با ایمیل طراحی شده بود.» این جمله شاید کمی بیانصافی باشد، اما روح ماجرا را نشان میدهد.
مشخصاتمحوری و حافظهی پروژه
یکی دیگر از پاسخها، تغییر خود فرایند است: بهجای اینکه عامل را با یک جملهی مبهم رها کنیم، اول مشخصات (Spec) را مینویسیم، بعد عامل آن را پیاده میکند. گیتهاب با Spec Kit این ایده را متنباز کرد و فایلهایی مثل AGENTS.md در پروژهها رایج شدند تا قواعد، محدودهی فایلها و انتظارات به عامل گفته شود.
این فایلها جای کامیت را نمیگیرند، اما شکاف «چرا» را پر میکنند. تاریخچهی گیت میگوید چه شد؛ مشخصات و فایل دستورالعمل میگویند چرا و زیر چه شرطی.
خود گیت هم در حال تغییر است
گیت ۲.۵۶ در سپتامبر ۲۰۲۶ منتشر شد با بهبودهایی که مستقیماً به درد مخازن بزرگ میخورند: پیدا کردن merge-base در یک مونوریپوی واقعی از ۰.۶۸ ثانیه به ۰.۰۱ ثانیه رسید، دستور git add --resolved اضافه شد تا فقط فایلهای درگیر تعارض stage شوند و بازسازی بستهها (repack) با --path-walk تا ۷۱٪ کوچکتر شد.
در افق دورتر، گیت ۳.۰ قرار است پیشفرض هش را از SHA-1 به SHA-256 تغییر بدهد. این تغییر امنیتی درست است، اما مهاجرت آن میتواند سالها دردسر بسازد: تغییر همهی objectها، شکستن امضاها، ابزارهایی که طول هش را ۴۰ کاراکتر فرض میکنند و مخازنی که نمیتوانند با هم حرف بزنند. بعضی شرکتها مثل گوگل حتی به فکر override کردن این پیشفرض برای پروژههای جدید هستند. نسخهکنترل، حتی بدون عاملها، هنوز یک مسئلهی حلنشده است.
وقتی مشکل از گیت نیست
در ژوئیه ۲۰۲۵، یک نمونهی معروف نشان داد که گیت همهچیز را نجات نمیدهد. بنیانگذار SaaStr با Replit یک محصول میساخت؛ عامل هوش مصنوعی نهتنها دیتابیس production را پاک کرد، بلکه مدتی با دادههای جعلی و تستهای ساختگی موضوع را پنهان کرد. نکتهی تلخ ماجرا این بود که کاربر صریحاً خواسته بود کد تغییر نکند.
اینجا مشکل از گیت نبود. گیت میتواند کد را برگرداند، اما دیتابیس، secretها و زیرساخت را برنمیگرداند. درس اصلی این است که در عصر عاملها، نسخهکنترل فقط یکی از لایههای ایمنی است. در کنارش به اینها نیاز داری:
- جداسازی کامل محیط توسعه، staging و production
- دسترسی حداقلی عامل و ممنوعیت لمس زیرساخت حیاتی
- بکاپ و توانایی بازگردانی واقعی، نه فقط ادعای آن
- تأیید انسانی برای عملیات پرخطر
- قفلهای فنی، نه «کد فریز» شفاهی
به عبارت دیگر، گیت تاریخچهی کد را ایزوله میکند؛ بقیهی سیستم را باید خودت ایزوله کنی.
نقش گیت در دورهی جدید
گیت قرار نیست حذف شود. نقشش عوض میشود: از یک ابزار دستی برای توسعهدهنده، به پروتکل زیرین تغییر تبدیل میشود. همانطور که کرنل جزئیات سختافزار را پنهان میکند و برنامهها روی آن ساخته میشوند، گیت هم دارد لایهای میشود که انسان، عامل و CI روی آن توافق میکنند.
چیزهایی که گیت در این دوره تضمین میکند:
- ردیابی: هر تغییر به یک کامیت، نویسنده و زمان مشخص وصل است.
- برگشتپذیری: هر تغییر قابل revert است؛ حتی اگر عامل اشتباه کرده باشد.
- ایزوله بودن: شاخهها و worktreeها اجازه میدهند چند عامل بدون تداخل کار کنند.
- دروازهی انسانی: پولریکوئست و بازبینی، جایی است که ماشین متوقف میشود و انسان تصمیم میگیرد.
- قرارداد مشترک: CI، ابزار بازبینی، مستندات و عاملها همه یک زبان مشترک دارند.
چیزی که عوض میشود، رابط است. عاملها بهجای دستورهای تعاملی، به API، MCP و دستورهای قابل اسکریپت نیاز دارند. شاخهها باید ارزان و موقت باشند. استک کردن تغییرات باید عادی شود. تاریخچه باید بتواند نویز عامل را قبل از رسیدن به main فشرده کند. و مهمتر از همه، بازبینی باید بر «قصد» تمرکز کند، نه فقط بر diff.
آینده ممکن است شبیه گیت امروز نباشد؛ ممکن است jj باشد، GitButler باشد یا چیزی که هنوز ساخته نشده. اما هر سیستمی که جای گیت را بگیرد، باید همان تضمینها را بدهد: هر تغییر قابل ردیابی، قابل بازبینی و قابل برگشت باشد. بدون این سه، عاملها فقط سرعت تولید آشوب را بالا میبرند.
یک چکلیست عملی برای تیمها
اگر امروز میخواهی عاملها را وارد جریان کار تیمت کنی، از این قاعدهها شروع کن:
- هر تسک، یک شاخه و یک worktree. هیچ دو عاملی روی یک working tree کار نکنند.
- کامیتهای کوچک با پیام معنادار. پیام باید بگوید «چرا»، نه فقط «چه فایلی عوض شد».
- main محافظتشده باشد. عامل هرگز مستقیم push نکند؛ فقط از طریق پولریکوئست.
- CI داور نهایی باشد. تست، lint، typecheck و اسکن امنیتی باید قبل از merge اجرا شوند.
- خروجی عامل را باور نکن. تست سبز بهتنهایی کافی نیست؛ باید مطمئن شوی تست واقعاً چیزی را که لازم است بررسی میکند.
- قبل از عملیات پرخطر چکپوینت بساز. تگ، بکاپ یا شاخهی جدا؛ راه برگشت باید از قبل آماده باشد.
- دسترسی را کم کن. عامل نباید به production، secretها یا حسابهای ابری دسترسی داشته باشد.
- برای مقیاس بزرگ آماده شو. Partial Clone، Sparse Checkout، Scalar و merge queue را جدی بگیر؛ و اگر درد تاریخچهنویسی زیاد شد، jj را امتحان کن.
جمعبندی
وایبکدینگ و کدنویسی عاملی، نوشتن کد را ارزان کردهاند. اما وقتی نوشتن ارزان شود، ارزش به جایی میرود که تغییرات را میفهمد، میسنجد و ادغام میکند. گیت دقیقاً همین جاست. شاید رابطش عوض شود، شاید ابزارهای بالای آن کاملاً متفاوت باشند، اما بدون یک لایهی نسخهکنترل قابل اعتماد، سرعت عاملها به سرعت بدهی فنی تبدیل میشود.
شرکتی که امروز فقط تعداد کامیتها را جشن میگیرد، فردا باید تاریخچهای را تمیز کند که هیچکس نمیتواند بخواند. شرکتی که از همین امروز شاخهی مستقل، بازبینی انسانی و بازگشتپذیری را جدی بگیرد، میتواند از عاملها بدون از دست دادن کنترل استفاده کند. گیت ابزار دوران قبل نیست؛ بستر دوران بعد است؛ به شرطی که برای دوران بعد بازطراحی شود.
اگر سؤالت این است که برای وایبکدینگ کدام زبان کمدردسرتر است، وایب کدینگ با کدام زبان راحتتر است؟ همین را با داده مقایسه کرده.
منابع
- Building Git infrastructure for agent-scale development — گیتهاب، اکتبر ۲۰۲۶
- We've raised $17M to build what comes after Git — GitButler، آوریل ۲۰۲۶
- Agent-safe Git with GitButler — GitButler، آوریل ۲۰۲۶
- Agentic Version Control Benchmarks — GitButler، ژوئیه ۲۰۲۶
- Grit: rewriting Git in Rust with agents — GitButler، ژوئن ۲۰۲۶
- Git Merge 2026 Talks — شامل گزارش jj و مهاجرت SHA-256
- Sapling SCM — مستندات متا
- Highlights from Git 2.56 — گیتهاب، سپتامبر ۲۰۲۶
- Replit deleted a production database — The Register، ژوئیه ۲۰۲۵