Git Worktrees در برابر روش‌های سنتی: مدیریت بدون تداخل در کدنویسی AI

تصور کنید سه عامل کدنویس مختلف را هم‌زمان روی یک پروژه رها کرده‌اید، اما هر کدام در حال بازنویسی فایل‌هایی هستند که دیگری به آن‌ها نیاز دارد. این تداخل بنیادین، بزرگ‌ترین گلوگاه برای هر توسعه‌دهنده‌ای است که می‌خواهد از Claude Code، Aider و Cursor به‌طور هم‌زمان روی یک مخزن (Repository) کار کند.

این مشکل دقیقاً زمانی رخ می‌دهد که عامل‌ها از رابط‌های ساده‌ی چت به بازیگران خودمختار در سیستم فایل تبدیل می‌شوند. همان‌طور که در تحلیل قبلی ما درباره‌ی شکست عامل‌های موازی در مقیاس بزرگ اشاره کردیم، ریشه‌ی مشکل اغلب در محیط اجراست، نه در خودِ مدل. اکثر توسعه‌دهندگان فعلاً از جابه‌جایی دستی با git stash یا کلون کردن چندین‌باره‌ی مخزن استفاده می‌کنند که برای پروژه‌های حجیم (Monorepos) بسیار ناکارآمد است.

شکست راهکارهای رایج

روش‌های سنتی مدیریت تسک‌های متعدد وقتی عامل‌ها وارد بازی می‌شوند، شکست می‌خورند:

• کلنجار با Git Stash: استش یک پشته‌ی مشترک است. وقتی سه عامل هم‌زمان اجرا شوند، نمی‌توانند روی ترتیب استش‌ها توافق کنند و نتیجه، کابوسی از جابه‌جایی شاخه‌ها و بازگرداندن تغییرات است.
• کلون‌های متعدد: کلون کردن N مرتبه از مخزن، N نسخه کامل از پوشه .git و N مجموعه وابستگی ایجاد می‌کند. این کار باعث ناهماهنگی تنظیمات شده و در پروژه‌های بزرگ به‌شدت کند است.
• زیرپوشه‌های تک‌شاخه: وقتی عامل‌ها در یک شاخه‌ی غول‌پیکر روی زیرپوشه‌های مختلف کامیت می‌کنند، تداخل‌های ادغام (Merge Conflicts) اجتناب‌ناپذیر می‌شود و عامل نمی‌تواند تغییرات خالص خود را ببیند.

به نقل از یک راهنمای فنی که در ۳۱ اوت ۲۰۲۶ در dev.to منتشر شد، راهکار نهایی Git Worktrees است. این قابلیت که از نسخه ۲.۵ گیت در سال ۲۰۱۵ معرفی شده، به کاربر اجازه می‌دهد چندین نسخه از یک مخزن را در دایرکتوری‌های مختلف داشته باشد، در حالی که همگی از یک پوشه .git واحد استفاده می‌کنند.

سازوکار Worktree

به‌جای تغییر شاخه در یک پوشه، شما برای هر عامل یک مسیر مجزا می‌سازید. این فرآیند با دستور git worktree add انجام می‌شود تا یک شاخه‌ی خاص به دایرکتوری جدید متصل شود. برای مثال:

git worktree add ../myapp-agent-a feature/agent-a
git worktree add ../myapp-agent-b feature/agent-b
git worktree add ../myapp-agent-c fix/flaky-test

برای مشاهده وضعیت، دستور git worktree list نقشه‌ی دقیقی از مسیرها و شاخه‌های متصل به آن‌ها ارائه می‌دهد.

این معماری مزایای فنی مشخصی دارد:

• ذخیره‌سازی یکپارچه: تمام ورک‌تری‌ها از یک ذخیره‌ساز .git/objects استفاده می‌کنند و جلوی اشغال فضای دیسک (که در کلون‌های متعدد رخ می‌دهد) را می‌گیرند.
• شفافیت آنی: کامیت‌های انجام شده در یک ورک‌تری، پس از fetch یا checkout، فوراً برای سایرین قابل مشاهده است.
• ایزولاسیون: هر دایرکتوری یک نسخه‌ی کامل و واقعی است. شما می‌توانید وارد آن شوید، تست‌ها را اجرا کنید یا یک عامل را به آن ارجاع دهید بدون اینکه ایندکس یا درخت کاری عامل دیگر تغییر کند.

پیاده‌سازی برای عامل‌ها

برای خودکارسازی این روند، توسعه‌دهندگان می‌توانند از اسکریپت‌های شل استفاده کنند. یک اسکریپت نمونه مانند spawn-agent.sh با استفاده از set -euo pipefail برای پایداری، یک شاخه‌ی منحصربه‌فرد بر اساس نام تسک (مثلاً agent/${task}) می‌سازد و ورک‌تری را در مسیری مانند ../$(basename "$(pwd)")-${task} مقداردهی می‌کند.

تنظیمات هر ورک‌تری حیاتی است تا عامل‌ها بر سر منابع مشترک نجنگند. یک اسکریپت قدرتمند باید:
۱. فایل .env.example را به .env در دایرکتوری جدید کپی کند.
۲. دستور npm install --prefer-offline را برای ایجاد وابستگی‌های محلی اجرا کند.

پاک‌سازی نیز ساده است. دستور git worktree remove ../myapp-agent-c کافی است، یا در صورت کثیف بودن دایرکتوری، از --force استفاده می‌شود.

حالت‌های شکست بحرانی

ورک‌تری‌ها بدون ریسک نیستند. طبق گزارش منبع مذکور، چند نکته‌ی کلیدی وجود دارد که می‌تواند جریان کاری را مختل کند:

• تداخل کش (Cache): کش‌های مشترک مدیران بسته (مثل npm یا pip) اگر چندین عامل هم‌زمان وابستگی‌ها را نصب کنند، دچار تداخل قفل (Lock Contention) می‌شوند. این اتفاق منجر به خراب شدن مخفیانه‌ی بیلدها در ورک‌تری‌های دیگر می‌شود. پیشنهاد می‌شود از کش مجزا برای هر ورک‌تری استفاده کنید: npm install --cache "$(pwd)/.npm-cache".
• سربار IDE: سرورهای زبان در VS Code یا JetBrains هر ورک‌تری را به‌طور مستقل ایندکس می‌کنند. این یعنی ۴ برابر مصرف حافظه برای سرورهای TypeScript. اگر عامل به‌صورت headless اجرا می‌شود، بهتر است پنجره IDE آن ورک‌تری بسته شود تا تداخل مسیرها پیش نیاید.
• قفل شدن شاخه: گیت اجازه نمی‌دهد دو ورک‌تری به یک شاخه اشاره کنند. این موضوع از تاریخچه‌های واگرا جلوگیری می‌کند اما نیازمند یک سیستم نام‌گذاری سخت‌گیرانه (هر عامل یک شاخه) است.
• HEADهای جدا شده (Detached): اگر عاملی به‌جای شاخه، یک کامیت خاص را چک‌اوت کند، تغییرات هنگام حذف ورک‌تری ممکن است از بین بروند. توصیه می‌شود قبل از حذف، دستور git branch tmp-recovery اجرا شود.

ساب‌مدول‌ها و هوک‌ها

هوک‌های استاندارد گیت در دایرکتوری مشترک .git قرار دارند. اگر هوکی فرض کند دایرکتوری جاری ریشه مخزن است، در ورک‌تری‌های مختلف شکست می‌خورد. همچنین ساب‌مدول‌ها به‌طور پیش‌فرض در git worktree add مقداردهی نمی‌شوند و باید از فلگ --recurse-submodules استفاده کرد.

برای مدیریت ۳ تا ۴ عامل، موثرترین الگو استفاده از یک چک‌اوت «هماهنگ‌کننده» (Orchestrator) برای بررسی و ادغام، و تخصیص ورک‌تری‌های یک‌بارمصرف به هر تسک است. پس از ادغام، ورک‌تری حذف و شاخه پاک می‌شود تا «سندباکس‌های زامبی» ایجاد نشوند.

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

گام بعدی شما

• تعداد دفعاتی که در روز از git stash استفاده می‌کنید را بررسی کنید؛ اگر زیاد است، وقت آن است که به سراغ ورک‌تری بروید.
• یک اسکریپت ساده برای spawn-agent بنویسید که به‌طور خودکار شاخه و دایرکتوری مجزا برای هر تسک ایجاد کند.
• برای جلوگیری از تداخل بیلدها، مسیر کش مدیر بسته (npm/pip) را برای هر ورک‌تری مجزا تعریف کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.