گیت دیگه کافی نیست
خلاصهٔ کاملتر
گیت دو کار انجام میده: ذخیرهسازی توزیعشده سورس کد، و مدیریت گردش کار توزیعشده. در کار اول بینظیره، اما در کار دوم مشکلات جدی داره که اکثر ما بهشون عادت کردیم و دیگه نمیبینیمشون. نویسنده این مقاله معتقده که گیت برای توسعهی واقعاً توزیعشده — چه با دیگران، چه بهصورت ناهمزمان با خودت — دیگه کافی نیست.
یکی از مشکلات اصلی، مدیریت Stacked PRs (پیآرهای تو در تو) هست. تصور کنید یه باگ رو فیکس میکنید، PR میفرستید، و بلافاصله یه فیچر جدید روی همون باگفیکس شروع میکنید. حالا اگه ترانک آپدیت بشه و بخواید rebase کنید، گیت هیچ ایدهای نداره که این دو تا برنچ با هم رابطه دارن. کامیتها در گیت هیچ اطلاعاتی از کامیتهای جانشین، تاریخچهی rebase، یا اینکه آیا خودشون «garbage» هستن یا نه، ندارن.
برنچها هم کمکی نمیکنن: یه برنچ به اسم wp/bugfix از trunk قابل دسترسی نیست چون هیچ forward reference ای وجود نداره. ابزارهایی مثل Graphite سعی کردن این مشکل رو حل کنن، ولی مجبورن یه فروشگاه جداگانهی متادیتا برای برنچها نگه دارن که میتونه با خود گیت از سینک خارج بشه.
مشکل دیگه، مدل mutability (قابلیت تغییرپذیری) گیته. گیت دو دنیای جداگانه داره: دنیای کامیتها و برنچها (ثابت و غیرقابل تغییر)، و دنیای staging و working copy (قابل تغییر ولی خارج از مدل اصلی). این دوگانگی باعث میشه یادگیری سختتر بشه، export عجیب به نظر برسه، و گردشهای کاری ناهمزمان که در اونا تغییرات در طول زمان عوض میشن، اصلاً قابل نمایش نباشن.
مثال ملموس: شما دارید روی یه فیچر کار میکنید که هنوز کامیت نشده. یه باگ مزاحم پیدا میکنید، میریم سراغش، فیکسش میکنیم و PR میفرستیم. حالا میخواید هم باگفیکس توی workspace باشه (چون کار رو راحتتر میکنه) هم فیچر جدیدتون رو مستقل پیش ببرید. با گیت این ممکن نیست — یا باید new-feature رو روی bugfix rebase کنید (که وابستگی مصنوعی ایجاد میکنه)، یا بعداً rebase رو undo کنید. ابزارهای مدرنتر مثل jj این مدل ذهنی رو بهصورت بنیادی تغییر میدن.
نویسنده نتیجه میگیره که گیت برای مدت طولانی پشت «state of the art» مونده. شرکتهایی مثل Meta سالهاست از سیستمهای داخلی استفاده میکنن که از گیت جلوترن. و با گسترش LLMها، توسعهی ناهمزمان بیشتر هم شده، نه کمتر — پس این مشکلات مهمتر از قبل هستن.
نکات کلیدی:
- گیت کامیتهایی میسازه که هیچ اطلاعاتی از جانشینها، تاریخچه rebase، یا garbage بودن خودشون ندارن
- مدیریت Stacked PRs در گیت شکنندهست و نیاز به ابزارهای جانبی داره
- دوگانگی مدل mutation (staging/working copy در برابر commits) یادگیری و گردش کار ناهمزمان رو سخت میکنه
- گیت نمیتونه بعضی از گردشهای کاری واقعی رو نمایش بده — مثل داشتن چند تغییر مستقل ولی همزمان در workspace
- jj به عنوان جایگزین پیشنهاد میشه که این مشکلات رو از پایه حل کرده
