Stacked PRs अब GitHub पर लाइव हैं
GitHub का नया stacked pull requests फीचर, जो अब public preview में है, developers को बड़े code changes को छोटे, dependent PRs की एक श्रृंखला में तोड़ने में मदद करने का लक्ष्य रखता है, ताकि उन्हें आसानी से review और merge किया जा सके। कई engineers उस workflow के लिए native support का स्वागत करते हैं जिसे वे पहले third-party tools या manual branching से emulate करते थे, और CI, review scope, तथा parallel work के लिए इसके लाभों को रेखांकित करते हैं। अन्य लोग तर्क देते हैं कि यह फीचर अधूरा, buggy, या well-structured commits के मुकाबले redundant है, और कुछ लोग GitHub की आलोचना करते हैं कि उसने Gerrit और Phabricator जैसे systems में मौजूद prior art को नज़रअंदाज़ किया या core review tooling को सुधारने के बजाय complexity की एक और परत ship कर दी।
समग्र प्रतिक्रिया
- कई लोग उत्साहित हैं; stacked PRs को GitHub के वर्षों के सबसे बड़े बदलावों में से एक और अन्य सिस्टमों की तुलना में लंबे समय से अनुपस्थित फीचर बताया जा रहा है।
- कुछ लोग इससे कम प्रभावित हैं, और इसे ज्यादातर उन पैटर्न्स पर “UI sugar” कह रहे हैं जिन्हें वे पहले से उपयोग करते थे (ऐसे PRs जो अन्य PR branches को target करते हैं)।
- कुछ लोगों को लगता है कि v1 के लिए यह देर से आया और बहुत बुनियादी/buggy है; जबकि कुछ बस खुश हैं कि यह एक और AI फीचर नहीं है।
समझी गई workflow लाभ
- बड़े features को छोटे, reviewable units में बाँटने देता है, जबकि काम बाद के हिस्सों पर जारी रह सकता है।
- parallel review सक्षम करता है: refactor → backend → frontend, अलग-अलग layers के लिए अलग reviewers के साथ।
- feature stack के subsets को merge करने का समर्थन करता है (जैसे, infra + API लेकिन UI नहीं) और हर unit के लिए CI चलाने देता है।
- stack management (dependent PRs का auto-rebasing, merge-one-or-merge-all) को manual rebasing की तुलना में बड़ा लाभ माना जा रहा है।
आलोचनाएँ और सीमाएँ
- कुछ लोगों के अनुसार stacked PRs organizational/review समस्याओं पर एक band-aid हैं; उनके हिसाब से बेहतर commit hygiene और छोटे, independent PRs बेहतर विकल्प हैं।
- चिंता है कि stacking complexity बढ़ाता है, long-lived branches को प्रोत्साहित करता है, और reviewers पर दबाव डालता है (“5-deep stack के bottom को बदलना painful है”).
- मौजूदा implementation में bugs हैं, खासकर stack को squash merge करने और merge-queue interactions के आसपास; cross-repo और full fork support अभी भी नहीं है।
- कई लोग कहते हैं कि यह कठिन समस्याएँ हल नहीं करता: messy local work को coherent series में reorder करना, true cross-repo stacks, या dependent changes के trees/graphs।
Review और UI संबंधी चिंताएँ
- GitHub में review की इकाई अभी भी PR है; commit-by-commit review awkward है, और comments evolving commits से साफ़-साफ़ map नहीं होते।
- कुछ लोग चाहते हैं कि GitHub ने diff/patch-series model अपनाया होता, जिसमें change IDs और interdiffs होते, जैसे Gerrit/Phabricator और बड़े internal forges में।
- stacks के लिए web UI को minimal माना जा रहा है; गंभीर users से अपेक्षा है कि वे CLI या custom tooling पर निर्भर रहें।
AI और व्यापक संदर्भ
- कई टिप्पणियाँ stacked PRs को बढ़ते AI-generated diff sizes और agent workflows से जोड़ती हैं, ताकि reviews को human-scale में रखा जा सके।
- अन्य लोग जोर देते हैं कि stacked workflows AI से बहुत पहले से मौजूद हैं; यह फीचर मुख्यतः एक स्थापित practice को mainstream बनाता है।