GitHub ने स्टैक्ड पुल रिक्वेस्ट (stacked pull requests) को पब्लिक प्रीव्यू में डाल दिया है, जिससे डेवलपर्स एक बड़े बदलाव को आश्रित (dependent) PRs की एक श्रृंखला में विभाजित कर सकते हैं, जिनकी स्वतंत्र रूप से समीक्षा और मर्ज की जा सकती है।

यह फीचर क्यों महत्वपूर्ण है

एक एकल, विशाल (monolithic) PR अक्सर महीने भर चलने वाली समीक्षा में बदल जाता है, जहाँ रिव्यूअर्स को असंबंधित कोड के बीच से गुजरना पड़ता है। जब बेस ब्रांच आगे बढ़ती है, तो उन बड़े बदलावों में मर्ज कॉन्फ्लिक्ट्स (merge conflicts) होने की संभावना बढ़ जाती है जो रिलीज़ को रोक देते हैं। स्टैक्ड PRs इन दोनों समस्याओं का समाधान करते हैं—एक बड़े डिफ (diff) को छोटे और केंद्रित डिफ (diffs) की एक श्रृंखला में बदलकर, जहाँ प्रत्येक अगला डिफ पिछले वाले पर आधारित होता है।

यह कैसे काम करता है

सबसे पहले मेन ब्रांच के खिलाफ पहला PR बनाएं, फिर अगले PR को पहले वाले पर बेस करें, तीसरे को दूसरे पर, और इसी तरह आगे बढ़ें। GitHub स्वचालित रूप से इन संबंधों को ट्रैक करता है: यदि आप बेस PR में संशोधन (amend) करते हैं, तो आश्रित PRs नए स्टेट को दर्शाने के लिए अपडेट हो जाते हैं। रिव्यूअर्स एक ही क्लिक के साथ पूरे स्टैक को अप्रूव कर सकते हैं या व्यक्तिगत लेयर्स को साइन-ऑफ कर सकते हैं।

  • रिव्यू एक सीमित दायरे में रहते हैं, जिससे फीडबैक जल्दी मिलता है।
  • कॉन्फ्लिक्ट्स कम हो जाते हैं क्योंकि प्रत्येक PR केवल अपने ही लेयर में पेश किए गए कोड को प्रभावित करता है।
  • UI स्टैक पदानुक्रम (hierarchy) दिखाता है, और GitHub CLI स्टैक्ड 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 बनाता है, जिनमें से प्रत्येक अपने से पहले वाले पर आश्रित है। यही वर्कफ़्लो वेब इंटरफेस के माध्यम से भी उपलब्ध है, जहाँ आप अन्य PRs को प्रभावित किए बिना स्टैक से किसी PR को पुनर्व्यवस्थित (reorder) या हटा (drop) सकते हैं।

किसे इससे लाभ होगा

बड़ी फीचर टीमें और ओपन-सोर्स मेंटेनर रिव्यूअर्स को असंबंधित बदलावों (churn) से बचाते हुए क्रमिक कार्य (incremental work) शिप कर सकते हैं। रिलीज़ मैनेजर्स को इस बात की स्पष्ट तस्वीर मिलती है कि क्या शिप करने के लिए तैयार है, क्योंकि प्रत्येक स्टैक लेयर को अपने स्वयं के शेड्यूल पर मर्ज किया जा सकता है।

ध्यान देने योग्य बातें

यह फीचर अभी प्रीव्यू में है, इसलिए पूर्ण रिलीज़ से पहले इसमें बदलाव हो सकते हैं। टीमों को ब्रांचिंग के संबंध में नई आदतें अपनानी होंगी और ऐसे मामलों (edge cases) का सामना करना पड़ सकता है जब किसी ऐसे स्टैक को रीबेस (rebase) किया जा रहा हो जिसे आंशिक रूप से पहले ही मर्ज किया जा चुका है। डॉक्यूमेंटेशन अभी भी विकसित हो रहा है, इसलिए शुरुआती अपनाने वालों (early adopters) को UI संकेतों को समझने में अतिरिक्त समय लग सकता है।

आगे क्या देखने को मिल सकता है

GitHub संभवतः कोड-ओनर्स (code-owners) और ऑटोमेशन टूल्स के साथ गहरा एकीकरण (tighter integration) लाएगा, और कॉन्फ्लिक्ट में कमी के मेट्रिक्स भी दिखा सकता है। GA (जनरल अवेलेबिलिटी) के समय के बारे में अपडेट के लिए प्रीव्यू अनाउंसमेंट पेज पर नज़र रखें।

Takeaway: स्टैक्ड पुल रिक्वेस्ट डेवलपर्स को बड़े बदलावों को नियंत्रित करने का एक व्यावहारिक तरीका देते हैं, जो एक एकल, कॉन्फ्लिक्ट-भारी PR को एक प्रबंधनीय और रिव्यू के अनुकूल क्रम में बदल देते हैं। यदि आपका वर्कफ़्लो लंबे रिव्यू और मर्ज की समस्याओं से जूझ रहा है, तो इस प्रीव्यू को आज़माना सार्थक है।