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

در ستایش Stacked PRs

“Stacked PRs” عمل تجزیه یک تغییر بزرگ به PRهای کوچکتر و جداگانه قابل بررسی است که می توانند به یکدیگر وابسته باشند و یک DAG را تشکیل دهند:

من در این مورد در پست خود در مورد git-branchless نوشتم، اما فکر می کنم خود تمرین شایسته پست خاص خود است.

چرا من اینقدر مشتاق روابط عمومی انباشته هستم؟

  • آنها ارسال PR های کوچکتر را تشویق می کنند. این به خودی خود بسیار دارد
    مزایای قابل اثبات. به طور خاص، روابط عمومی کوچکتر عبارتند از:

    • … بررسی آسان‌تر و سریع‌تر، زیرا بازبین تغییرات کمتری برای ثبت نام دارد.
    • … اگر باعث شکستگی شوند، برگشت به عقب آسان تر است.
  • انباشتن روابط عمومی باعث می‌شود نویسنده از انسداد خارج شود.
    • نویسندگان قبل از شروع به ایجاد چیزی در بالای آن تغییرات، نیازی به انتظار برای ادغام یک تغییر خاص ندارند.
    • این امر باعث می‌شود نویسندگان نسبت به زمان بازبینی هر روابط عمومی خاص حساسیت کمتری داشته باشند، زیرا می‌توانند تغییرات جدید را با توجه به اینکه تغییرات قدیمی‌تر هنوز در حال بررسی هستند، بنویسند.
  • انباشتن PR به شما امکان می دهد تغییرات وابسته را به راحتی مدیریت کنید.
    • از آنجایی که انباشتن PR به شما امکان می دهد یک DAG از تغییرات وابسته ایجاد کنید، این امر به طور طبیعی به شما امکان می دهد تا تغییرات کدی را که باید با ترتیب خاصی ارسال شوند، مدیریت کنید.

ویژگی های حیاتی برای اجرای PR های پشته ای:

  • توانایی همگام سازی درخت PRs با بالادست به راحتی، در حالی که ساختار DAG را حفظ می کند.
    • به طور مشابه: توانایی بالا بردن محتوای محلی PR تا ابزار متمرکزی که برای بررسی کد استفاده می شود.
  • توانایی گنجاندن تغییرات در یک PR، و انتشار/ادغام آسان آن تغییرات در وابستگان آن.
  • قابلیت تنظیم مجدد PR ها.
    • به عنوان مثال: تغییر والد یک PR، تنظیم مجدد ترتیب PR در “پشته”، افزودن یک PR جدید بین 2 PR موجود و غیره.
  • توانایی ایجاد یک روابط عمومی که تفاوت آن را با روابط عمومی دیگر نشان می دهد. یعنی تفاوت نمایش داده شده هنگام بررسی کد از PR “والد” خود به عنوان پایه استفاده می کند.
  • قابلیت جابجایی سریع بین PR.
  • امکان مشاهده اندازه یک PR، برای تبلیغ اینکه به راحتی قابل بررسی است
    روابط عمومی کوچک.
    (h/t FeepingCreature )
  • امکان مشاهده PR DAG هر دو به صورت محلی و در ابزار بررسی کد.

درخواست‌های کششی پشته‌ای در مقابل تعهدات پشته‌ای

“Pull Request” در Git معنای خاصی دارد، اگرچه به مرور زمان به معنای چیزی معادل “تغییر لیست” یا “پچ” است. برای الگوی “انباشتگی”، نکته مهم این است که واحدهای اتمی تغییرات کد را می توان (1) به عنوان DAG سفارش داد و (2) به طور مستقل بررسی کرد. این پست واقعاً باید چیزی شبیه به این نامگذاری شود “در ستایش “واحدهای کد قابل بررسی جداگانه”، اما این خیلی کمتر جذاب است.

جایگزین «درخواست‌های کششی پشته‌ای»، «تعهدات پشته‌ای» است. تفاوت عمدتاً عملی است: PRهای پشته‌ای از شاخه‌ها استفاده می‌کنند و می‌توانند چندین commit در یک تغییر اتمی داشته باشند. commit های انباشته از یک commit به عنوان واحد تغییر اتمی استفاده می کنند.

Github رویکرد Stacked PR را تشویق می کند، در حالی که ابزارهایی مانند Gerrit commit های پشته ای را تشویق می کنند. من شخصاً متعصب هستم که کدام رویکرد بهتر است. من با استفاده از Stacked Commits بیشتر آشنا هستم، اما به نظر می رسد با این رویکرد در حال مبارزه با git هستید – زیرا از استفاده از شاخه ها اجتناب می کنید.

هر یک از این رویکردها از استفاده از ابزارهای تخصصی سود زیادی می برد. وانیل git CLI می توان برای هر یک از این رویکردها استفاده شود، اما شما بیشتر از زمانی که فکر می‌کنم عاقلانه است، وقت خود را صرف انجام عملیات‌های اصلاحی commit/branch سطح پایین می‌کنید.

  • git-machete – شعار:
    «احتمالاً واضح‌ترین سازمان‌دهنده مخزن git و ابزار اتوماسیون گردش کار rebase/ادغام که تا به حال دیده‌اید»

    • در حال حاضر، این ابزار مورد علاقه من برای Stacked PRs است.
  • git-branchless – شعار:
    گردش کار در مقیاس مونورپو با سرعت بالا برای Git

    • این ابزار مورد علاقه من برای Stacked Commits است. همچنین با در نظر گرفتن عملکرد ساخته شده است، که هنگام کار بر روی مونورپوهای بزرگ کمک می کند.
  • git-stack – شعار: “مدیریت شعبه انباشته برای Git”
    • من از این مورد به اندازه کافی استفاده نکرده ام تا نظری در مورد آن داشته باشم، اما برای کار با Stacked PRs مفید به نظر می رسد – زیرا رویکردی دارد که “شاخه ها واحد کار و بررسی هستند”

لینک منبع

ارسال یک پاسخ

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