GitHub ने स्टॅक्ड पुल रिक्वेस्ट्स (stacked pull requests) पब्लिक प्रिव्ह्यूमध्ये आणले आहेत, ज्यामुळे डेव्हलपर्स मोठ्या बदलांचे रूपांतर एकमेकांवर अवलंबून असलेल्या PRs च्या साखळीत करू शकतात, ज्यांचे स्वतंत्रपणे रिव्ह्यू आणि मर्ज केले जाऊ शकते.

ही वैशिष्ट्ये का महत्त्वाची आहेत

एकच मोठा (monolithic) PR अनेकदा महिनाभर चालणाऱ्या रिव्ह्यूमध्ये रूपांतरित होतो, ज्यामध्ये रिव्ह्यूअर्सना असंबद्ध कोड तपासावा लागतो. जेव्हा बेस ब्रांच बदलली जाते, तेव्हा अशा मोठ्या बदलांमध्ये मर्ज कॉन्फ्लिक्ट्स (merge conflicts) येण्याची शक्यता असते, ज्यामुळे रिलीजमध्ये अडथळा येऊ शकतो. स्टॅक्ड PRs या दोन्ही समस्या सोडवतात; ते एका मोठ्या बदलाचे रूपांतर लहान आणि केंद्रित बदलांच्या मालिकेत करतात, ज्यातील प्रत्येक बदल मागील बदलावर आधारित असतो.

हे कसे कार्य करते

प्रथम मुख्य (main) ब्रांचवर पहिला PR तयार करा, त्यानंतर पुढचा PR पहिल्यावर आधारित ठेवा, तिसरा दुसऱ्यावर, आणि असेच पुढे सुरू ठेवा. GitHub आपोआप या संबंधांचा मागोवा घेते: जर तुम्ही बेस PR मध्ये बदल केला, तर अवलंबून असलेले 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 तयार करते, ज्यातील प्रत्येक PR मागील PR वर अवलंबून आहे. हेच वर्कफ्लो वेब इंटरफेसद्वारे देखील उपलब्ध आहे, जिथे तुम्ही इतर PRs ला धक्का न लावता स्टॅकमधून एखादा PR काढून टाकू शकता किंवा त्याचा क्रम बदलू शकता.

कोणाला याचा फायदा होईल

मोठ्या फीचर टीम्स आणि ओपन-सोर्स मेंटेनर्स रिव्ह्यूअर्सना असंबद्ध बदलांचा त्रास न देता टप्प्याटप्प्याने काम पूर्ण करू शकतात. रिलीज मॅनेजर्सना कोणते काम रिलीजसाठी तयार आहे याचे स्पष्ट चित्र मिळते, कारण स्टॅकचा प्रत्येक लेयर त्याच्या स्वतःच्या वेळापत्रकानुसार मर्ज केला जाऊ शकतो.

लक्षात घेण्यासारख्या काही गोष्टी

हे वैशिष्ट्य अजूनही प्रिव्ह्यूमध्ये आहे, त्यामुळे पूर्ण रिलीजपूर्वी त्यात बदल होऊ शकतात. टीम्सना ब्रांचिंगबाबत नवीन सवयी लावाव्या लागतील आणि अंशतः मर्ज केलेल्या स्टॅकचा रीबेस (rebase) करताना काही तांत्रिक अडचणी (edge cases) येऊ शकतात. डॉक्युमेंटेशन अजूनही तयार होत आहे, त्यामुळे सुरुवातीच्या वापरकर्त्यांना UI समजून घेण्यासाठी अतिरिक्त वेळ लागू शकतो.

पुढे काय अपेक्षित आहे

GitHub बहुधा कोड-ओनर्स (code-owners) आणि ऑटोमेशन टूल्ससोबत अधिक घनिष्ठ एकत्रीकरण (integration) आणेल आणि कॉन्फ्लिक्ट कमी होण्याबाबतचे मेट्रिक्स देखील उपलब्ध करून देऊ शकते. GA (general availability) च्या वेळेबद्दल अपडेट्ससाठी प्रिव्ह्यू अनाउन्समेंट पेजवर लक्ष ठेवा.

थोडक्यात सांगायचे तर: स्टॅक्ड पुल रिक्वेस्ट्स डेव्हलपर्सना मोठ्या बदलांना हाताळण्याचा एक व्यावहारिक मार्ग देतात, ज्यामुळे एक मोठा आणि कॉन्फ्लिक्ट्सने भरलेला PR व्यवस्थापित करण्यायोग्य आणि रिव्ह्यूसाठी सोप्या मालिकेत रूपांतरित होतो. जर तुमच्या वर्कफ्लोमध्ये लांब रिव्ह्यू आणि मर्ज करण्याच्या अडचणी येत असतील, तर हे प्रिव्ह्यू वापरून पाहण्यासारखे आहे.