GitHub قابلیت stacked pull requests را به مرحله پیش‌نمایش عمومی (public preview) منتقل کرده است که به توسعه‌دهندگان اجازه می‌دهد یک تغییر بزرگ را به زنجیره‌ای از PRهای وابسته تقسیم کنند که می‌توان هر کدام را به‌طور مستقل بازبینی و ادغام (merge) کرد.

چرا این قابلیت اهمیت دارد

یک PR واحد و حجیم (monolithic) اغلب به یک فرآیند بازبینی طولانی، مثلاً یک ماهه، تبدیل می‌شود که در آن بازبین‌ها مجبورند میان کدهای بی‌ربط جستجو کنند. وقتی شاخه پایه (base branch) تغییر می‌کند، این تغییرات عظیم مستعد تداخل‌های ادغام (merge conflicts) هستند که باعث توقف روند انتشارها می‌شوند. PRهای پشته‌ای (Stacked PRs) با تبدیل یک تغییر بزرگ به مجموعه‌ای از تغییرات (diffs) کوچک‌تر و متمرکز که هر کدام بر پایه قبلی ساخته شده‌اند، هر دو مشکل را حل می‌کنند.

نحوه عملکرد

ابتدا اولین PR را نسبت به شاخه اصلی (main branch) ایجاد کنید، سپس PR بعدی را بر پایه اولی، PR سوم را بر پایه دومی و به همین ترتیب پیش بروید. GitHub روابط را به‌طور خودکار دنبال می‌کند: اگر PR پایه را اصلاح کنید، PRهای وابسته به‌روزرسانی می‌شوند تا وضعیت جدید را منعکس کنند. بازبین‌ها می‌توانند کل پشته را تنها با یک کلیک تأیید کنند یا هر لایه را به‌طور جداگانه بررسی و تأیید نمایند.

  • بازبینی‌ها در محدوده محدودی باقی می‌مانند که باعث سرعت بخشیدن به دریافت بازخورد می‌شود.
  • تداخل‌ها کاهش می‌یابند، زیرا هر PR فقط کدهایی را تغییر می‌دهد که در لایه مخصوص به خود معرفی شده‌اند.
  • رابط کاربری (UI) سلسله‌مراتب پشته را نشان می‌دهد و GitHub CLI یک دستور تک‌خطی برای ایجاد مجموعه‌ای از PRهای پشته‌ای ارائه می‌دهد.
gh pr create --title Feature A --base main
gh pr create --title Feature B --base feature-a
gh pr create --title Feature C --base feature-b

مثال خط فرمان، سه PR متصل به هم ایجاد می‌کند که هر کدام به قبلی وابسته است. همین گردش کار از طریق رابط کاربری وب نیز در دسترس است، جایی که می‌توانید ترتیب یک PR را در پشته تغییر دهید یا آن را بدون از کار انداختن سایر موارد، حذف کنید.

چه کسانی از این قابلیت بهره می‌برند

تیم‌های بزرگ توسعه ویژگی و نگهدارندگان پروژه‌های متن‌باز می‌توانند کارهای مرحله‌ای خود را بدون درگیر کردن بازبین‌ها با تغییرات بی‌ربط و پراکنده، منتشر کنند. مدیران انتشار نیز تصویر روشن‌تری از آنچه آماده ارسال است به دست می‌آورند، زیرا هر لایه از پشته می‌تواند طبق برنامه زمانی خودش ادغام شود.

نکات و محدودیت‌هایی که باید در نظر گرفت

این قابلیت هنوز در مرحله پیش‌نمایش است، بنابراین ممکن است قبل از انتشار نهایی تغییر کند. تیم‌ها باید عادت‌های جدیدی را در زمینه شاخه‌بندی (branching) اتخاذ کنند و ممکن است هنگام بازسازی پایه (rebasing) پشته‌ای که بخشی از آن قبلاً ادغام شده است، با موارد خاص (edge cases) مواجه شوند. مستندات هنوز در حال تکمیل است، بنابراین کاربران اولیه ممکن است زمان بیشتری را صرف یادگیری نشانه‌های رابط کاربری کنند.

گام‌های بعدی و آنچه باید منتظر آن بود

احتمالاً GitHub ادغام تنگاتنگ‌تری با ابزارهای خودکارسازی و code-owners ایجاد خواهد کرد و ممکن است معیارهایی را برای کاهش تداخل‌ها ارائه دهد. صفحه اعلان پیش‌نمایش را برای اطلاع از زمان عرضه نسخه عمومی (GA) دنبال کنید.

نکته کلیدی: stacked pull requests روشی کاربردی به توسعه‌دهندگان ارائه می‌دهد تا تغییرات عظیم را مهار کنند و یک PR واحد و پر از تداخل را به یک توالی قابل مدیریت و مناسب برای بازبینی تبدیل کنند. اگر گردش کار شما با بازبینی‌های طولانی و دردسرهای ادغام دست‌وپنجه نرم می‌کند، این نسخه پیش‌نمایش ارزش امتحان کردن را دارد.