GitHub Stacked PRs

 (github.github.com/gh-stack)
10 पॉइंट द्वारा GN⁺ 2026-04-14 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े code changes को छोटे, review किए जा सकने वाले PR units में विभाजित करके क्रमवार प्रबंधित करने देने वाला GitHub का नया फीचर
  • हर PR का स्वतंत्र रूप से review किया जाता है, और पूरी stack को एक क्लिक में merge किया जा सकता है
  • GitHub UI और gh stack CLI के ज़रिए stack बनाना, नेविगेट करना, rebase करना, और merge करना समर्थित है, और stack map से hierarchy को विज़ुअलाइज़ किया जाता है
  • AI coding agent integration के माध्यम से बड़े diff को अपने-आप stack units में बांटा जा सकता है या stack-आधारित development किया जा सकता है
  • इसका उद्देश्य बड़े PRs की complexity और conflict risk को कम करना, और review efficiency तथा team development speed को बढ़ाना है

मुख्य फीचर्स

  • Stack-आधारित PR management

    • कई PRs को क्रमबद्ध stack के रूप में व्यवस्थित किया जाता है, जहाँ हर PR अपने ठीक नीचे वाले PR की branch पर आधारित होता है
    • इससे अंततः main branch तक पहुँचने वाली chain structure बनती है
    • GitHub पूरी stack को पहचानकर UI में stack map दिखाता है, ताकि reviewer हर layer को आसानी से देख सके
    • Branch protection rules अंतिम target branch पर लागू होते हैं, और CI tests stack के सभी PRs पर चलाए जाते हैं

  • सरल stack management

    • GitHub UI में stack के भीतर PRs के बीच जाना, हर layer की स्थिति देखना, और पूरी stack पर cascading rebase चलाना संभव है
    • एक क्लिक में पूरी stack को merge किया जा सकता है, या उसका कुछ हिस्सा ही merge किया जा सकता है
    • merge के बाद बचे हुए PRs अपने-आप rebase हो जाते हैं, जिससे सबसे नीचे का unmerged PR base branch के अनुसार समायोजित हो जाता है

  • मज़बूत CLI support

    • gh stack CLI के जरिए stack बनाना, rebase करना, branch push करना, PR बनाना, और layers के बीच जाना terminal से किया जा सकता है
    • CLI command examples
      • gh extension install github/gh-stack : extension install करें
      • gh stack alias : shortcut commands सेट करें
      • gs init <branch> : पहली branch बनाएं
      • gs add <branch> : नई layer जोड़ें
      • gs push : सभी branches push करें
      • gs submit : पूरी stack के PRs बनाएं

  • AI Agent integration

    • npx skills add github/gh-stack command से AI coding agent को stack tasks करने के लिए सिखाया जा सकता है
    • बड़े diff को अपने-आप stack units में बांटा जा सकता है, या शुरुआत से stack-आधारित development किया जा सकता है

Stack-आधारित PRs की ज़रूरत

  • बड़े PRs से review की कठिनाई बढ़ती है, merge में देरी होती है, और conflict risk बढ़ता है
    • reviewer context खो सकते हैं, feedback की गुणवत्ता गिरती है, और पूरी team की गति धीमी हो जाती है
  • Stacked PRs इसे हल करने के लिए changes को छोटी और focused PR chain में बाँटते हैं
    • हर PR का स्वतंत्र review किया जा सकता है, और पूरे changes क्रमवार जुड़ते जाते हैं

शुरुआत करें

संबंधित पढ़ाई

2 टिप्पणियां

 
tested 1 일 전

Stacked PRs फ़िलहाल private preview में है। यह फीचर तब तक काम नहीं करेगा जब तक आपके repository के लिए इसे enabled नहीं किया जाता।
 
GN⁺ 2026-04-14
Hacker News की राय

  • मुझे "stacked PR" नहीं, बल्कि single commit management के लिए UI चाहिए

    • मैं कुछ commits को अलग से merge करना चाहता हूँ, या किसी खास commit को review complete के रूप में mark करना चाहता हूँ
    • मैं commit स्तर पर interactive rebase/squash/edit करना चाहता हूँ, लेकिन GitHub UI में यह संभव नहीं है
    • commit message या किसी खास commit पर comment करने की सुविधा, और diff of diff के जरिए force push के बीच हुए बदलावों को visualize करने की सुविधा चाहिए
      Git में पहले से commit का concept है, तो समझ नहीं आता कि उसके ऊपर फिर "stacked PR" जैसा abstraction क्यों रखा जा रहा है
    • यह Phabricator के बनाए stacked diff workflow को GitHub में लाने का concept है
      इससे अभी merge न हुए काम के ऊपर नया काम आगे बढ़ाना आसान हो जाता है, और reviewer बड़े बदलावों को छोटी इकाइयों में स्वतंत्र review कर सकते हैं
      बड़े monorepo या enterprise environment में यह खास तौर पर उपयोगी था
    • लेकिन मुझे git history को लगातार rewrite करना जोखिम भरा लगता है
      बार-बार squash, rebase, force push करना अपने ही पैर पर कुल्हाड़ी मारने जैसा लगता है
      git merge --no-ff, git log --first-parent, git bisect --first-parent से भी काफी हद तक वही असर मिल सकता है
    • Meta में इस्तेमाल होने वाला SuperSmartLog(SSL) सबसे बेहतरीन implementation था
      यह interactive smartlog दस्तावेज़ में public है और इसका VSCode extension भी है
      अफसोस है कि यह उम्मीद के मुताबिक व्यापक रूप से इस्तेमाल नहीं हो पाया
    • मेरा पसंदीदा workflow यह है कि PR/MR को "atomic change" के रूप में देखा जाए
      commits का उपयोग उस PR को पूरा करने की evolving process के रूप में किया जाए
      1. अगर PR बहुत बड़ा हो, तो उसे commits में बाँटें
      2. PR के विकसित होने की प्रक्रिया commits में दर्ज करें (जैसे "foo को bar में बदला" जैसी वजहों सहित)
    • जो तुम कह रहे हो, वह असल में Gerrit है

  • Phabricator और Mercurial इस्तेमाल करने के बाद GitHub पर लौटना पाषाण युग में वापस जाने जैसा लगता है
    stacked diff flow को फिर से लागू करने वाले jujutsu या इस नई feature को देखकर अच्छा लगा
    यह सिर्फ monorepo ही नहीं, लंबे समय तक चलने वाले feature development में भी review को छोटा और तेज़ बनाता है

    • अच्छा हुआ कि DVCS युद्ध में Git जीत गया
      Mercurial हमेशा कहता था कि वह "git से तेज़ है", लेकिन व्यवहार में वह धीमा था या टूट जाता था
      Git बदसूरत है, लेकिन तेज़ और भरोसेमंद है
    • मुझे अब भी GitHub review पसंद नहीं, इसलिए मैं Gerrit इस्तेमाल करता हूँ
      बड़े बदलावों (जैसे vendor dependency update) की review करते समय GitHub का file review experience खास अच्छा नहीं है
    • Phabricator का review UI बहुत याद आता है

  • आखिरकार आ गया!
    GitHub का "PR=branch" मॉडल मुझे कभी समझ नहीं आया
    Phabricator/Gerrit-style stacked commit मेरे सोचने के तरीके से ज़्यादा मेल खाता है
    अब लगता है CLI install करना पड़ेगा

    • GH CLI पर dependency थोड़ा खटकती है, लेकिन उम्मीद है GA तक UI support आ जाएगा
    • मेरे दिमागी मॉडल में branch और stacked PR का फर्क साफ नहीं है
      branch तो बस commit पर झंडा लगाने जैसा है, और कई points छोड़ने का मतलब तभी बनता है जब पहले वाले हिस्सों को स्वतंत्र रूप से merge किया जा सके

  • जिज्ञासा है कि क्या इससे मौजूदा Squash & Merge UX problem हल हुई है
    मैं manually main <- PR A <- PR B <- PR C की तरह stack बनाता हूँ,
    PR A पहले merge हो जाए तो PR B conflict के नरक में फँस जाता है
    GitHub UI target branch को अपने-आप main में बदल देता है और अजीब conflicts पैदा हो जाते हैं
    बस ऐसा tool चाहिए जो "बस ठीक से काम करे"

    • conflicts शायद इसलिए हो रहे हैं क्योंकि PR A को squash merge किया गया था
      उम्मीद है gh stack sync इसे rebase --onto से संभाल लेगा
    • असल में CLI और server पर यह git rebase --onto से ही handle होता है
      उदाहरण: PR1(main<-A,B), PR2(main<-A,B,C,D), PR3(main<-A,B,C,D,E,F)
      अगर PR1,2 squash merge हो जाएँ, तो main में S1(A+B), S2(C+D) होगा
      उसके बाद git rebase --onto S2 D branch3 से बिना conflict के चीज़ें व्यवस्थित हो जाती हैं
    • मेरे workflow में अगर A merge हो गया, तो B भी पहले से merged होना चाहिए
      git rebase --update-refs --onto origin/main A C से इसे हल किया जा सकता है
      GH CLI इस प्रक्रिया को automate कर देता है
    • यह समस्या git की logical limitation है, bug नहीं
    • मैं भी मानता हूँ कि यह काफ़ी झुंझलाहट भरा और गैर-सहज है
      लेकिन समाधान आखिरकार manual rebase करके commits को ठीक करना ही है

  • अकेले development करते समय stacked PR की ज़रूरत कम पड़ती है, लेकिन छोटे units में बाँटने की आदत फिर भी महत्वपूर्ण है
    AI tools (जैसे Claude Code) एक बार में बड़ा diff बना देते हैं,
    इसलिए अगर agent खुद काम को logical units में बाँट सके तो वह दिलचस्प होगा

    • PR पहले से कई commits से बन सकता है, इसलिए अगर agent उन्हें ठीक से navigate नहीं कर पाता, तो stacked PR के साथ भी वही समस्या होगी
    • मैं Claude और jj को साथ में इस्तेमाल करता हूँ, ताकि work stack को trunk के ऊपर review-friendly तरीके से दोबारा व्यवस्थित किया जा सके
    • अगर छोटे branches को एक-दूसरे पर dependent बना दें, तो पहले वाले branch के update होने पर sync का नरक पैदा हो जाता है
    • संबंधित agent integration guide वेबपेज पर देखी जा सकती है

  • git-spice भी देखने लायक है
    यह GitLab आदि के साथ compatible है, और मैं मौजूदा git commands की जगह पूरी तरह git-spice इस्तेमाल करता हूँ

  • यह अच्छा है कि GitHub ने आखिरकार UI में stack feature जोड़ दिया
    यह GitLab के glab stack जैसा है
    लेकिन merge process थोड़ा awkward लगती है — stack के नीचे वाले हिस्से को merge करने पर बाकी का rebase होगा और CI फिर से चलेगा
    अगर तीन patches में से नीचे के दो ही merge करने हों, तो हर एक के लिए test का इंतज़ार करना पड़ेगा

    • मौजूदा design के हिसाब से, अगर नीचे के दो PR की CI pass हो जाए, तो उन्हें एक साथ merge किया जा सकता है
      उसके बाद ऊपर का stack rebase होगा और CI फिर से चल सकती है
      इस हिस्से को docs में और स्पष्ट रूप से जोड़ने की योजना है

  • मुझे stacked PR की ज़रूरत ठीक से समझ नहीं आती
    git में मूल रूप से patch sets को अलग-अलग review और apply किया जा सकता है
    PR model उल्टा इसे एक ही बड़े पैकेज में बाँध देता है
    stacked PR उस समस्या को bypass करने के लिए एक और abstraction जैसा लगता है

    • जिन teams में मैंने काम किया, वहाँ PR को ही "apply करने योग्य न्यूनतम इकाई" माना जाता है
      अंदर के commits सिर्फ development history होते हैं, और merge के समय उन्हें squash करके एक में मिला दिया जाता है
      इससे development के दौरान commits स्वतंत्र रूप से जमा किए जा सकते हैं, और merge के समय सिर्फ साफ बदलाव बचता है
    • Phabricator में commit और diff का 1:1 संबंध था, इसलिए वह कहीं ज़्यादा natural लगता था
      GitHub की implementation थोड़ी जबरन चिपकाई गई feature जैसी लगती है
    • PR मूल रूप से atomic change unit है, और stacked PR उसके ऊपर नए PR के आधार पर काम करने की सुविधा देता है
      यानी यह काम को reviewable units में चरणबद्ध तरीके से stack करने की संरचना है

  • Graphite नाम का startup पहले से stacked PR पर फोकस कर रहा है
    मैं Graphite इस्तेमाल करता रहा हूँ, इसलिए GitHub को ऐसा कुछ बनाते देखना अच्छा लगा

    • हमारी company में भी Graphite इस्तेमाल होता है और हम उससे संतुष्ट हैं

  • मुझे stacked PR पसंद हैं, लेकिन GitHub की यह implementation थोड़ी अजीब लगती है
    बस इतना काफी होना चाहिए कि हर branch अपने parent को point करे
    CLI से ज़्यादा UI support की ज़रूरत है

    • लेकिन parent branch merge होने के बाद rebase दर्दनाक हो जाता है
      अगर CLI इस प्रक्रिया को automate कर दे, तो अच्छा होगा
    • CLI optional है, और UI में भी stacked PR बनाए जा सकते हैं
      branch chain रखने की वजह यह है कि diff सिर्फ उसी branch के बदलाव दिखाए
    • सच तो यह है कि यह मूल git में भी संभव था
      बस UI और visualization की कमी थी
    • उम्मीद है अगला कदम UI improvements होगा