اگه پول داشتم، GitHub خودمو میساختم!
هوش مصنوعیخلاصهٔ کاملتر
نویسنده با یه بازی فکری شروع میکنه: اگه پولهای کلان داشتم، به جای راکت فضایی یا زیردریایی، یه فورج کد میساختم. این حرف از یه ناامیدی واقعی میاد؛ GitHub که روزگاری ابزار اصلی توسعهدهندهها بود، حالا داره از وظیفه اصلیش دور میشه.
مشکل اول اینه که گیت اصلاً برای کرنل لینوکس طراحی شده؛ یه سیستم توزیعشده مبتنی بر patch و ایمیل. ولی در عمل، اکثر تیمها از گیت فقط به عنوان یه راه push و pull به یه ریپوی مرکزی استفاده میکنن. همه چیز مهم — PR، اکشن، ایشو، ریلیز — داخل فورج اتفاق میافته، نه توی کلاینت.
یکی از بزرگترین دردسرها اینه که فیدبک بعد از کامیت میاد، نه قبلش. نویسنده اشاره میکنه که همه با اون PRهایی آشنان که کامیتهاشون اینجوریه: "Feature"، "fix"، "fix again"، "actually fix"، "please"، و آخرش یه "asdfasdf" ساعت ۱۱:۴۷ شب. راهحل؟ Pre-commit hookهای ریموت روی فورج که قبل از push، تستها رو اجرا کنن و فیدبک بدن.
مشکل بعدی سیستم approval بولین PRهاست. یا approve هست، یا نیست. ولی واقعیت کار تیمی پیچیدهتره. گاهی میگی "خب، بذار بره، بعداً درستش میکنیم." این یه گزینه مشروعه که باید بهعنوان یه دکمه رسمی وجود داشته باشه. ابزاری مثل Gerrit این مدل رو بهتر پیاده کرده.
PRها همچنین انعطاف کافی ندارن. تو دنیایی که LLM وجود داره، نیازی نیست یه مهندس ارشد ۴ ساعت منتظر باشه کسی یه PR چهار خطی رو approve کنه. باید بشه تعریف کرد که اگه تغییر کمریسکه و LLM سبزش کرد، مستقیم merge بشه. Stacked PRها هم باید شهروند درجه یک باشن، نه یه add-on خارجی.
نویسنده معتقده فورج نباید همه کاره بشه. Issue tracking؟ بله. Kanban؟ احتمالاً نه. Wiki؟ بعید. ابزارهایی که میخوان همه کاره باشن، معمولاً همه چیز رو خراب میکنن — چون فیچر اضافه کردن آسونه ولی نگهداری اون فیچرها برای همیشه گرونه.
واحد میزبانی هم خیلی بزرگه. راهاندازی GitHub Enterprise یا GitLab کار سنگینیه. نویسنده میخواد واحدهای کوچیکتری که بشه به هم وصل کرد؛ مثلاً ۱۲ تا Raspberry Pi که با هم یه org تشکیل بدن. کلون محلی باید نمایش کاملی از ریپو باشه — حتی ایشوها و PRها — نه فقط کد. و بالعکس، نباید مجبور باشی همه تاریخچه رو همیشه داشته باشی؛ Shallow clone پیشفرض باشه و تاریخچه قدیمیتر on-demand فچ بشه.
در نهایت، اکشنها باید امن، sign شده و قابل اجرا به صورت آفلاین باشن. باید بشه tarball اکشنها رو توی ریپو نگه داشت و گفت "از اینترنت چیزی نگیر." نویسنده میگه ابزارهایی مثل JJ بهعنوان VCS و مفاهیمی مثل object storage و shallow clone پایه خوبی دارن، ولی کسی لازمه همه اینها رو کنار هم بذاره و یه تجربه منسجم بسازه. تا اون روز، همه ما داریم PRهای "asdfasdf" میزنیم و منتظریم یه ربات چکشون کنه.
نکات کلیدی:
- GitHub و فورجهای مشابه از نحوه واقعی استفاده روزمره از گیت فاصله گرفتن
- فیدبک باید قبل از کامیت بیاد، نه بعدش — با pre-commit hookهای ریموت
- سیستم approval باید از بولین فراتر بره و گزینههای میانی داشته باشه
- PRها باید انعطافپذیرتر باشن؛ LLM میتونه ریسک تغییرات رو ارزیابی کنه
- فورج نباید همهکاره بشه؛ سادگی و تمرکز مهمتره
- واحد میزبانی باید کوچیکتر و ماژولارتر باشه
- اکشنها باید sign شده، قابل آفلاین و قابل نگهداری داخل ریپو باشن
- Shallow clone باید پیشفرض باشه و تاریخچه قدیمی on-demand لود بشه
