GitHub نے stacked pull requests کو پبلک پریویو (public preview) میں منتقل کر دیا ہے، جس سے ڈویلپرز کو ایک بڑی تبدیلی کو منحصر PRs کی ایک زنجیر میں تقسیم کرنے کی سہولت ملے گی جن کا الگ الگ ریویو اور مرج کیا جا سکتا ہے۔

یہ فیچر کیوں اہم ہے

اکثر ایک ہی بڑی (monolithic) PR مہینوں تک جاری رہنے والے ریویو میں بدل جاتی ہے، جہاں ریویو کرنے والوں کو غیر متعلقہ کوڈ دیکھنا پڑتا ہے۔ جب بیس برانچ (base branch) تبدیل ہوتی ہے، تو ان بڑی تبدیلیوں میں مرج کنفلیکٹس (merge conflicts) کا خطرہ بڑھ جاتا ہے جو ریلیز میں رکاوٹ ڈالتے ہیں۔ Stacked PRs ان دونوں مسائل کو حل کرتے ہیں، کیونکہ یہ ایک بڑے فرق (diff) کو چھوٹے اور مرکوز فرقوں کی ایک سیریز میں بدل دیتے ہیں، جن میں سے ہر ایک پچھلے والے پر مبنی ہوتا ہے۔

یہ کیسے کام کرتا ہے

پہلی PR کو مین برانچ کے خلاف بنائیں، پھر اگلی PR کو پہلی پر، تیسری کو دوسری پر، اور اسی طرح آگے بڑھیں۔ GitHub خودکار طور پر ان تعلقات کو ٹریک کرتا ہے: اگر آپ بیس PR میں ترمیم کرتے ہیں، تو منحصر PRs نئے اسٹیٹ کو ظاہر کرنے کے لیے اپ ڈیٹ ہو جاتی ہیں۔ ریویو کرنے والے پورے اسٹیک (stack) کو ایک کلک سے منظور کر سکتے ہیں یا انفرادی لیئرز کو چیک کر سکتے ہیں۔

  • ریویوز ایک محدود دائرہ کار تک رہتے ہیں، جس سے فیڈ بیک تیزی سے ملتا ہے۔
  • کنفلیکٹس کم ہو جاتے ہیں کیونکہ ہر PR صرف اپنے لیئر کے کوڈ کو تبدیل کرتی ہے۔
  • UI اسٹیک کی درجہ بندی (hierarchy) دکھاتا ہے، اور GitHub CLI کے ذریعے ایک ہی کمانڈ سے stacked PRs کی سیریز بنائی جا سکتی ہے۔
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

کمانڈ لائن کی یہ مثال تین منسلک PRs بناتی ہے، جن میں سے ہر ایک اپنے سے پہلے والی PR پر منحصر ہے۔ یہی ورک فلو ویب انٹرفیس کے ذریعے بھی دستیاب ہے، جہاں آپ دوسروں کو متاثر کیے بغیر اسٹیک سے کسی PR کی ترتیب بدل سکتے ہیں یا اسے نکال سکتے ہیں۔

اس سے کن لوگوں کو فائدہ ہوگا

بڑی فیچر ٹیمیں اور اوپن سورس مینٹینرز (open-source maintainers) ریویو کرنے والوں کو غیر متعلقہ تبدیلیوں سے بچاتے ہوئے بتدریج کام مکمل کر سکتے ہیں۔ ریلیز مینیجرز کو اس بات کا واضح تصور ملتا ہے کہ کیا چیز ریلیز کے لیے تیار ہے، کیونکہ اسٹیک کی ہر لیئر کو اپنے شیڈول کے مطابق مرج کیا جا سکتا ہے۔

قابلِ غور احتیاطی تدابیر

یہ فیچر ابھی پریویو میں ہے، اس لیے مکمل ریلیز سے پہلے اس میں تبدیلیاں ہو سکتی ہیں۔ ٹیموں کو برانچنگ کے حوالے سے نئی عادات اپنانی ہوں گی اور ایسے اسٹیک کو ری بیس (rebase) کرتے وقت ایج کیسز (edge cases) کا سامنا کرنا پڑ سکتا ہے جو پہلے ہی جزوی طور پر مرج ہو چکا ہو۔ دستاویزات (documentation) ابھی تیار ہو رہی ہیں، اس لیے ابتدائی استعمال کرنے والوں کو UI کے اشاروں کو سمجھنے میں اضافی وقت صرف کرنا پڑ سکتا ہے۔

آئندہ کیا متوقع ہے

GitHub ممکنہ طور پر code-owners اور آٹومیشن ٹولز کے ساتھ مزید گہرا انٹیگریشن فراہم کرے گا، اور کنفلیکٹس میں کمی کے میٹرکس بھی دکھا سکتا ہے۔ GA (general availability) کے وقت کے بارے میں اپ ڈیٹس کے لیے پریویو اناؤنسمنٹ پیج پر نظر رکھیں۔

خلاصہ: Stacked pull requests ڈویلپرز کو بڑے پیمانے پر ہونے والی تبدیلیوں کو قابو میں رکھنے کا ایک عملی طریقہ فراہم کرتے ہیں، جو ایک ہی، کنفلکٹ سے بھرپور PR کو ایک قابلِ انتظام اور ریویو کے لیے آسان ترتیب میں بدل دیتے ہیں۔ اگر آپ کا ورک فلو طویل ریویوز اور مرج کے مسائل سے لڑ رہا ہے، تو اس پریویو کو آزمانا فائدہ مند ہو سکتا ہے۔