تصور کنید پنج برنامه نویس جونیور همزمان روی یک فایل کار میکنند و هر کدام سعی دارند کد خود را روی سرور بفرستند؛ نتیجه چیزی نیست جز هرجومرج و تداخلهای بیپایان. اگر از عاملهای هوش مصنوعی برای کدنویسی موازی استفاده میکنید، احتمالاً با کابوس تداخل در شاخه اصلی (Main Branch) آشنا هستید.
طبق مستندات پروژه در گیتهاب، ابزاری به نام claude-code-merge-queue در ۳۰ جولای ۲۰۲۶ منتشر شد تا این مشکل را حل کند. این ابزار با معرفی یک صف FIFO (اولین ورودی، اولین خروجی)، فرآیند ارسال کد توسط عاملها (Agents) — که مانند دستیارانی هستند که میتوانند بهطور مستقل کد بزنند و اجرا کنند — را متوالی میکند تا هیچکدام با هم برخورد نکنند.
همانطور که در تحلیل قبلی ما دربارهی مدیریت محیطهای مجزا برای حسابهای موازی اشاره کردیم، گلوگاه بعدی همیشه «ارسال کد» یا همان Git Push است. در حالی که اجرای چندین عامل ممکن است، اما ارسال همزمان آنها به شاخه اصلی، باعث ایجاد بیلدهای سنگین تکراری و ناپایداری در تستها میشود، چرا که منابع مشترک سیستم تحت فشار قرار میگیرند. این چالشها بهخصوص برای کسانی که از ابزارهای واسط استفاده میکنند مشهودتر است؛ برای مثال، ابزار cursor-bridge پیشتر دسترسی رایگان به Claude Code را برای کاربران Cursor فراهم کرد تا توسعهدهندگان بتوانند سریعتر این قابلیتها را در محیطهای متنوع تست کنند.
به گزارش توسعهدهنده این پروژه، این ابزار جایگزینی رایگان برای Merge Queue ابری گیتهاب است. برخلاف نسخه گیتهاب که برای هر تلاش هزینهی دقایق GitHub Actions میگیرد، این صف بهصورت محلی روی سیستم توسعهدهنده اجرا میشود. بر خلاف نسخه ابری، این ابزار نیازی به ایجاد Pull Request ندارد و تنها از طریق یک Rebase و Push مستقیم عمل میکند.
زمینه و راهاندازی
برای شروع کار، ابتدا باید ابزار را از طریق npm نصب کنید: npm install --save-dev claude-code-merge-queue (یا معادلهای آن در pnpm، yarn و bun) و سپس دستور npx claude-code-merge-queue init را اجرا کنید.
فرآیند مقداردهی اولیه، چندین فایل حیاتی را در مخزن میسازد. فایل claude-code-merge-queue.config.mjs را ایجاد میکند که شامل شاخههای ادغام شناساییشده و دستورات بررسی (check commands) است. همچنین فایل CLAUDE.md بهروزرسانی میشود تا به هوش مصنوعی زاینده (Generative AI) — شبیه به یک نویسنده خبره که بر اساس الگوهای آماری متن تولید میکند — دستور دهد کدها را پس از سبز شدن تستها ارسال کند. جهت بهینهسازی این فرآیند، میتوان از الگوهای استاندارد در فایل CLAUDE.md برای کاهش زمان پیکربندی بهره برد تا هماهنگی بین عامل و مخزن سریعتر برقرار شود. علاوه بر این، هوک WorktreeCreate را در فایل .claude/settings.json سیمکشی میکند.
برای امنیت بیشتر، این ابزار تنظیمات .husky/pre-push را مدیریت میکند. اگر Husky در پروژه حضور نداشته باشد، ابزار بهجای تغییر مخفیانه در .git/hooks/pre-push کاربر را باخبر میکند. همچنین مجموعهای از اسکریپتها برای عملیات land، sync، promote و preview به package.json اضافه شده و فایل claude-code-merge-queue-preflight.mjs بهعنوان یک شبکه ایمنی برای تشخیص شاخههای قدیمی (stale) پیش از شکست، تعریف میشود.
جزئیات فنی
این سامانه از یک زیرساخت تخصصی برای ایزولهسازی و نظم بخشیدن به گردشکار عاملها استفاده میکند:
- لاینهای شمارهدار: هر عامل در یک Worktree مجزا (مثلاً
lane/1یاlane/2) با پوشههای اختصاصی که دارای پسوند-lane-هستند فعالیت میکند. آنها از پورتهای مجزا استفاده میکنند که از یکportBaseقابل تنظیم (به صورت پیشفرض ۳۰۰۰) شروع میشوند. - ارسال جراحیشده: دستور
landکد یک لاین را از طریق صف FIFO روی شاخه ادغام Rebase و Push میکند. این مکانیسم از رقابت در ارسال (Push Race) جلوگیری میکند؛ به این معنا که دو لاین هرگز بهطور همزمان در حال Push نیستند. - گیتهای خودکار: ابزار با استفاده از
checkCommand(مثلاًnpm run check) بررسی میکند که کد «سبز» باشد. اگر هیچ دستور بررسی پیکربندی نشده باشد، تمام Pushها بهطور پیشفرض شکست میخورند تا از ارسال تصادفی بیلدهای خراب جلوگیری شود. - قفل بیلد: دستور
build-lockیک دستور مشخص را بهصورت متوالی روی تمام لاینها در سطح ماشین اجرا میکند تا از مصرف بیش از حد CPU و اتمام منابع سختافزاری جلوگیری شود. - مدیریت وضعیت: دستور
syncباعث بهروزرسانی سریع (Fast-forward) شاخه اصلی در محیط Checkout میشود و اگر lockfile تغییر کرده باشد، وابستگیها را مجدداً نصب میکند. دستورpreviewنیز درخت کاری زنده یک لاین، شامل تغییرات ثبتنشده (uncommitted)، را روی Checkout اصلی منعکس میکند.
پیکربندی و حفاظها
اکثر تنظیمات در فایل claude-code-merge-queue.config.mjs قرار دارند. فیلدهای کلیدی شامل integrationBranch (محل فرود عاملها)، productionBranch (برای مدلهای دو مرحلهای) و protectedBranches برای اعمال محدودیتهای اضافی است. برای جلوگیری از مسدود شدنهای بیهوده، کاربران میتوانند regenerableFiles (فایلهایی که ابزار هنگام Rebase نادیده میگیرد) و buildOutputDirs (مانند dist یا .next) را تعریف کنند تا این پوشهها هنگام جابجایی بین Checkoutها کپی نشوند.
این ابزار از «شکستهای مرموز» دوری میکند. اگر پیکربندی اشتباه باشد — مثلاً مقدار پورت منفی باشد یا نام شاخه خالی رها شده باشد — ابزار فوراً و با صدای بلند خطا داده و تمام مشکلات را در لحظه بارگذاری دستور لیست میکند.
برای جلوگیری از قفل شدن کامل سیستم، توسعهدهنده یک «دریچه اضطراری» تعبیه کرده است. با تنظیم متغیر محیطی CLAUDE_CODE_MERGE_QUEUE_EMERGENCY_PUSH=1 انسان میتواند بهصورت اجباری کد را از طریق git push origin HEAD:main روی هر شاخه محافظتشده Push کند. این تنها یک قرارداد برای جلوگیری از اشتباهات انسانی است، نه یک مرز امنیتی در برابر عاملهای مخرب.
این ابزار گردشکار عاملهای هوش مصنوعی را از «موازیسازی امیدوارانه» به «همروندی ساختاریافته» تغییر میدهد. با انتقال صف ادغام از ابر به ماشین محلی، هزینه تکرار با ۵ یا ۱۰ عامل همزمان به صفر میرسد.
برای شما به این معناست که میتوانید با عاملها مانند یک تیم مهندسی جونیور رفتار کنید. دیگر نیاز نیست هر Push را بهصورت دستی نظارت کنید یا یک تداخل (Merge Conflict) یکسان را سه بار حل کنید چون سه عامل مختلف سعی کردهاند همزمان یک باگ را بگیرند.
محدودیتهای شناختهشده
با این حال، سیستم محدودیتهای مشخصی دارد. این ابزار برای یک ماشین طراحی شده، نه یک ناوگان (Fleet)؛ چون صف FIFO در حافظه موقت محلی (Local Temp Storage) ذخیره میشود، اگر دو ماشین همزمان اقدام به ارسال کنند، خطای استاندارد Git (non-fast-forward rejection) رخ میدهد. همچنین هیچ مرحلهای برای بررسی انسانی وجود ندارد و تنها گیت ورودی، عبور از checkCommand است.
کندی checkCommand سقف توان عملیاتی را تعیین میکند. چون قفل FIFO برای کل مدت زمان اجرا نگه داشته میشود، یک مجموعه تست ۴ دقیقهای، سیستم را به کمتر از ۲۰ ارسال موفق در هر ساعت محدود میکند. در نهایت، تداخلهای Rebase همیشه منجر به git rebase --abort میشوند تا درخت کد تمیز بماند و سپس مدل باید طبق دستورالعمل CLAUDE.md تداخل را بهصورت دستی حل کند.
توسعهدهندگانی که اکنون از این ابزار استفاده میکنند باید ادغام این صف در فایل .claude/settings.json را برای خودکارسازی کامل چرخه ارسال و همگامسازی بررسی کنند. گام منطقی بعدی، رصد افزونههای جامعهمحور است که ممکن است این سریالسازی محلی را به سایر چارچوبهای عاملمحور (Agentic Frameworks) فراتر از Claude منتقل کنند.
گام بعدی شما
- ادغام این صف در فایل
.claude/settings.jsonبرای خودکارسازی چرخه ارسال و همگامسازی. - تست کردن
build-lockبرای جلوگیری از کرش کردن سیستم هنگام اجرای همزمان چندین تست سنگین توسط عاملها. - بررسی افزونههای جامعهمحور برای انتقال این ساختار به سایر چارچوبهای عاملمحور.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو