مشکلی که باعث شد سراغ Worktree برم

فرض کن رو یه پروژه واقعی کار می‌کنی، یه اپ که هم بک‌اند داره هم فرانت‌اند هم اپلیکیشن موبایل. می‌خوای هم‌زمان دو تا تغییر مجزا روی کد بدی؛ مثلاً یکی داره روی آنبوردینگ کار می‌کنه، یکی داره یه بخش دیگه رو حذف می‌کنه. حالا اگه به جای خودت، دو تا ایجنت هوش مصنوعی رو هم‌زمان بذاری روی این کار — مثلاً Claude Code یکی رو انجام بده و Cursor یکی دیگه رو — دقیقاً همون مشکلی پیش میاد که وقتی دو تا دولوپر رو یه فولدر مشترک کد می‌زنن پیش میاد: فایل‌ها قاطی می‌شن، یکی وسط ادیت کردنه، اون یکی می‌خواد بیلد بگیره، ارور می‌خوره، فکر می‌کنه خودش مشکل داره در حالی که یه تغییر ناتموم از یه ایجنت دیگه‌ست که وسط کاره. اینجا دقیقاً جاییه که Git Worktree وارد می‌شه.

Git Worktree دقیقاً چیست

هر ریپازیتوری گیت به‌صورت پیش‌فرض یک working directory داره — یعنی یه کپی فعال از کد که روش کار می‌کنی. اگه بزنی:

git worktree list

می‌بینی فقط همون یه دونه working tree لیست شده. Worktree یه قابلیت گیت هست که بهت اجازه می‌ده بدون کلون کردن دوباره‌ی کل پروژه، یه کپی سبک و سریع از آخرین نسخه‌ی کد رو تو یه فولدر دیگه بسازی. فرقش با کلون کردن اینه که تاریخچه رو نمی‌کشه، فقط آخرین وضعیت کد رو می‌ذاره جلوت. نکته‌ی کلیدی اینه: تغییراتی که تو یه worktree می‌دی، هیچ تداخلی با تغییراتی که تو worktree دیگه در حال انجامه نداره.

دستورهایی که باید بلد باشی

ساختن یه worktree جدید روی یه برنچ جدید:

# دیدن worktree های فعلی
git worktree list

# ساختن یه worktree جدید توی یه فولدر کنار پروژه اصلی، روی یه برنچ جدید
git worktree add ../project-feature-x -b feature-x

# می‌ری تو همون فولدر و مثل یه کپی جدا از پروژه روش کار می‌کنی
cd ../project-feature-x

بعد از این‌جا، این فولدر برای خودش یه پروژه‌ی کامل و مستقله. می‌تونی توش IDE باز کنی، اپ رو بیلد بگیری، تست کنی، بدون این‌که به هیچ‌وجه رو کد worktree اصلی اثر بذاره.

وقتی کار تموم شد و می‌خوای تغییرات رو برگردونی به برنچ اصلی:

# برمی‌گردی به worktree اصلی
cd ../project

# مطمئن می‌شی رو برنچ main هستی
git checkout main

# تغییرات worktree جدید رو مرج می‌کنی
git merge feature-x

# و بعد از merge، worktree که دیگه لازم نداری رو پاک می‌کنی
git worktree remove ../project-feature-x

بعد از این دستور آخر، اون فولدر جداگانه‌ای که ساخته بودی به‌طور کامل از بین می‌ره.

چرا این برای کار با چند ایجنت هم‌زمان حیاتیه

فرض کن یه ایجنت داره رو worktree اصلی، تغییرات آنبوردینگ رو پیاده می‌کنه — این کار ممکنه چند دقیقه طول بکشه. تو همون لحظه می‌خوای یه تغییر کوچیک دیگه رو با یه ایجنت دیگه هم‌زمان انجام بدی. اگه هر دو رو مستقیم رو همون فولدر اصلی بذاری، این اتفاق می‌افته: یکی وسط نوشتن کده، اون یکی می‌خواد بیلد بگیره و کد نصفه‌کاره‌ی اولی رو می‌بینه، ارور می‌گیره، و چون نمی‌دونه ارور مال یه تغییر دیگه‌ست، وقتشو تلف می‌کنه. با worktree، این دو تا ایجنت عملاً روی دو تا کپی کاملاً جدا از کد کار می‌کنن. این یعنی می‌تونی همزمان چند ایجنت رو رها کنی هرکدوم رو یه بخش از کار.

نکته‌ی مهم دیگه: وقتی داری تو worktree اصلی روی یه بخش بیلد می‌گیری، اون بیلد فقط تغییرات همون worktree رو می‌بینه. اگه بخوای وضعیت worktree دیگه رو چک کنی، باید یه پروژه‌ی جدا (مثلاً یه IDE window دیگه) روی همون فولدر باز کنی.

خبر خوب اینه که Cursor هم از worktree به‌صورت built-in پشتیبانی می‌کنه؛ تو تنظیمات ایجنت‌ها می‌تونی worktree رو فعال کنی و تا ۲۵ تا worktree هم‌زمان مدیریت کنه. وقتی یه تسک جدید به یه ایجنت می‌دی، خودش یه worktree می‌سازه، ایجنت توش کار می‌کنه، و بعد از این‌که کارش تموم شد و merge کردی، خودش worktree رو پاک می‌کنه.

چرا از Claude Code به Cursor سوییچ کردم

دلیل اصلی سوییچ، محدودیت (rate limit) بود. وقتی داری با Opus کار می‌کنی و روی effort بالا گذاشتیش، مصرف weekly limit خیلی سریع بالا می‌ره؛ تو یه جلسه‌ی کاری معمولی می‌شه به راحتی ۹۰ درصد سهمیه رو مصرف کرد. وقتی این اتفاق می‌افته، منطقی نیست دست رو دست بذاری و منتظر ریست شدن سهمیه بمونی.

Cursor برای تغییرات کوچیک و مشخص خیلی خوب عمل می‌کنه، مخصوصاً با مدل Composer. اگه بدونی دقیقاً چه تغییری می‌خوای بدی و محدوده‌ش کوچیکه، Composer سریع جواب می‌ده و کیفیت خروجی هم قابل قبوله. نکته‌ی منفی‌ش اینه که سهمیه‌ی Cursor هم ماهانه‌ست نه روزانه، و اگه زیاد استفاده کنی می‌بینی خیلی سریع تمومش می‌کنی.

نکته‌ی مهم‌تر اینه که انتخاب مدل برای هر ایجنت باید بر اساس سطح دسترسی‌ای باشه که بهش می‌دی. وقتی یه ایجنت به سرورت SSH وصله و می‌تونه هر کامندی رو اجرا کنه، عملاً همون ایجنت ادمین سرورته — هر تغییری که بخواد می‌تونه رو دیتابیس و پیکربندی سرور اعمال کنه. برای این سطح دسترسی، مدل‌های ضعیف یا رایگان اصلاً گزینه نیستن؛ حتی مدل‌های میان‌رده هم برای این کار ریسکی‌ان. برای کارهای حساس روی سرور، فقط از قوی‌ترین مدل‌های در دسترس استفاده کن، و برای کارهای کوچیک و ایزوله می‌تونی مدل‌های سریع‌تر و ارزون‌تر رو بذاری کار کنن.

در نهایت رویکرد درست، وفاداری به یه ابزار نیست. Claude Code برای کارهایی که نیاز به context عمیق و فهم تصمیمات پروژه دارن گزینه‌ی قوی‌تریه. Cursor برای تغییرات نقطه‌ای و سریع، وقتی محدودیت Claude اذیتت می‌کنه یا فقط می‌خوای موازی کار کنی، گزینه‌ی خوبیه. Codex و Antigravity هم به‌عنوان بک‌آپ‌های اضطراری وقتی همه‌چیز محدود شده به کار میان. اما مستقل از این‌که کدوم ابزار رو انتخاب می‌کنی، یه قانون ثابت می‌مونه: کد رو کورکورانه قبول نکن. فقط چک کردن این‌که تست پاس شده کافی نیست؛ باید ببینی معماری کد هم منطقی هست یا نه.

اگه دوست داری ویدئوش رو هم ببینی، لینکش پایین صفحه‌ست.