لینک کوتاه مطلب : https://hsgar.com/?p=4859

بعد از Git چه می آید

Git از مشکلات همکاری در هسته لینوکس متولد شد. نزدیک به یک دهه بعد، زمانی که Kubernetes (سیستم عامل ابر) همکاری منبع باز را به سطح جدیدی آورد، مشکلات جدیدی به وجود آمد.

من نقاط دردناک git (و GitHub) را از نزدیک دیدم که روی منبع باز Kubernetes کار می کردند. آیا یک سیستم کنترل نسخه جدید (یا چیزی که مشکلات مشابه را حل می کند) ظاهر می شود؟

چند ایده در مورد اینکه یک سیستم کنترل نسخه جدید چگونه خواهد بود.

  • اتمی بودن در پروژه ها – GitHub یک است عملا monorepo و به این صورت استفاده می شود. تقسیم کد با وابستگی ها می تواند منجر به همگام سازی پیچیده و خطوط لوله CI شود. زیر ماژول ها راه حل مناسبی نیستند.
  • مدیریت بسته بومی – بسته‌ها به شدت با کد همراه هستند (به مدیر بسته گمشده GitHub مراجعه کنید). ذخیره‌سازی آدرس‌پذیر محتوای Git به ما می‌گوید که از مجموعه فایل‌های مناسبی برای بازبینی استفاده می‌کنیم. همچنین باید در هنگام مصرف سورس کد از طریق مدیران بسته، ضمانت مشابهی داشته باشیم. بهتر از این، شاید بتوانیم اصول اولیه عمومی را به سمت یک مدیر بسته جهانی بسازیم.
  • تفاوت معنایی – آیا می‌توانیم نحوه استفاده از کنترل نسخه را برای داشتن ادغام‌های آگاه از زمینه بیشتر دریابیم؟ آیا می توانید باور کنید که ما هنوز بر الگوریتم تفاوت متن از سال 1976 (و کاستی های آن) تکیه می کنیم؟ Git هنوز با تغییر نام فایل مشکل دارد. GitHub Copilot، اما برای تضادهای ادغام? تفاوت معنایی قبلاً امتحان شده است، اما پیاده سازی های خاص زبان احتمالاً هرگز کار نمی کنند.
  • ادغام ساختار داده صف – دو درخواست کشش به طور همزمان تمام تست ها را با موفقیت پشت سر می گذارند اما در صورت ادغام با یکدیگر شکست می خورند. در حالی که بیشتر یک ویژگی گردش کار است تا یک ویژگی کنترل نسخه، به اندازه کافی برای ایده ردیابی تاریخچه (یعنی ساختن نمودار تعهد) هسته ای است که می توان یک مورد قوی برای تبدیل آن به یک شهروند درجه یک ایجاد کرد.
  • درخواست‌های خروج فن – این ایده که صاحبان کتابخانه می‌توانند یک پچ برای نرم‌افزار خود بنویسند و آن را بین همه کاربران پایین‌دستی توزیع کنند. در حالی که کاربران پایین دستی موظف به به روز رسانی نیستند، می تواند کار زیادی را از N مصرف کننده مختلف در پی بردن به نحوه ارتقاء ببرد. به dependabot فکر کنید، اما با انواع به‌روزرسانی‌ها (کوچک، امنیتی و خرابی). در داخل شرکت ها بسیار مفید است، اما یک آنالوگ ممکن است در منبع باز منطقی باشد.
  • UX وحشتناک Git – دستورات بیش از حد و ناسازگار و موارد دیگر. من معتقدم که مشکل اساسی، واگرایی گردش کار از ابزار است. هر دو git باید به طور کامل از درخواست کشش جدا شود و گردش کار ادغام شود یا در آنچه اکنون به “جریان git” تبدیل شده است، ادغام شود.
  • ذخیره سازی فایل های بزرگ – پسوندهایی مانند وجود دارد git lfs که تا حدودی از فایل های بزرگتر پشتیبانی می کنند اما عالی نیستند. به نظر می رسد که یک میخ مربع را در یک سوراخ گرد قرار دهید. به نظر نمی‌رسد که اکثر گردش‌های کاری به پشتیبانی دارایی‌های بزرگ نیاز داشته باشند – فقط توسعه بازی و سایر موارد. اما، تصور می‌کنم اگر آن را به روشی ارگونومیک حل کنیم، جریان‌های کاری جدیدی را باز می‌کنیم که هرگز فکر نمی‌کردیم انجام دهیم – مانند ذخیره دارایی‌های باینری یا عکس‌های فوری پایگاه داده در کنار کد. چرا همه چیز را اگر آسان و ارزان است نسخه نکنید؟
  • قلاب های مدیریت پروژه، اما نه ویژگی ها – آیا مسائل و ردیابی اشکال باید در سیستم کنترل نسخه تعبیه شود؟ این همان فلسفه است فسیلی. مدیریت پروژه به قدری بی شکل و زودگذر است که من فکر نمی کنم باید آن را در فناوری پایه قرار داد. با این حال، یک VCS جدید باید قلاب‌ها و API‌هایی را که اجازه می‌دهند ابزار مدیریت پروژه با طعم لحظه‌ای در بالا ساخته شود، آشکار کند.



لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.