GitHub Stacked PR का public preview शुरू

 (github.blog)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े बदलावों को छोटे, review करने योग्य layers में बाँटने वाले Stacked pull requests अब सभी repositories में public preview के रूप में चरणबद्ध तरीके से उपलब्ध कराए जा रहे हैं
  • हर PR अपने ठीक नीचे वाली layer को target करता है, जिससे टीम के सदस्य सीमित दायरे वाले diff का parallel में independently review कर सकते हैं
  • सबसे नया PR merge करने पर उसके नीचे की सभी unmerged layers भी एक साथ शामिल हो जाती हैं, और अगर केवल कुछ हिस्से merge किए जाएँ तो ऊपर वाले PR अपने-आप rebase होकर target बदल लेते हैं
  • मौजूदा PR review, required checks, branch protection, और merge requirements वैसे ही लागू रहते हैं, और stacks को GitHub.com, CLI, mobile app, और GitHub Copilot में संभाला जा सकता है
  • public preview आने वाले कुछ दिनों में सभी repositories तक बढ़ाया जाएगा, और Merge queue support अगले कुछ हफ्तों में धीरे-धीरे उपलब्ध होगा

छोटे बदलावों को stack करने वाली PR संरचना

  • बड़े बदलावों को कई छोटे और focused PR में बाँटा जाता है, और हर PR को क्रमबद्ध change layer के रूप में व्यवस्थित किया जाता है
  • पहले बदलाव के लिए branch और PR बनाने के बाद, उसके ऊपर नई branch और PR जोड़ी जाती हैं, और हर PR अपने ठीक नीचे वाली layer को target करता है
  • इससे एक बहुत बड़े PR को review करने या कई branches को बार-बार manually rebase करने की असुविधा कम होती है
  • Next.js टीम का कहना है कि बड़े features release करते समय भी वे individual changes को छोटा रख पाए, जिससे PR review आसान हो गया

stack बनाना और working environment

  • CLI extension को इस कमांड से install किया जा सकता है
gh extension install github/gh-stack
  • GitHub.com, GitHub CLI, और GitHub mobile app में stacks बनाए और manage किए जा सकते हैं
  • GitHub Copilot जैसे coding agents में gh-stack skill का इस्तेमाल किया जा सकता है

layer-दर-layer independent review

  • stack के अंदर कोई PR खोलने पर पूरे बदलाव के बजाय केवल उस layer का diff review किया जा सकता है
  • PR के ऊपर दिखने वाले stack map में यह देखा जा सकता है कि मौजूदा बदलाव पूरे काम में कहाँ स्थित है
  • टीम के सदस्य अलग-अलग layers को parallel में review कर सकते हैं, इसलिए बाद का काम review पूरा होने तक रुका नहीं रहता
  • मौजूदा branch protection rules और layer-based review को साथ में लागू करके हर चरण की quality manage की जा सकती है
  • TED ने बताया कि AI अपनाने के बाद development productivity बढ़ी, लेकिन PR बड़े होने से review bottleneck बनने लगा; इसके बाद उन्होंने बदलावों को dependency order के अनुसार छोटे logical units में बाँटा, जिससे review की speed और accuracy बढ़ी

पूरे stack या उसके कुछ हिस्से को merge करना

  • जब सबसे नया PR तैयार हो जाए, तो उसे merge करने पर वह PR और उसके नीचे की सभी unmerged layers एक साथ लागू हो जाती हैं
  • stack के निचले हिस्से की एक या अधिक layers को चुनकर पहले merge भी किया जा सकता है
    • ऊपर वाले PR खुले रहते हैं
    • merged बदलावों के अनुसार वे अपने-आप rebase होते हैं और target branch भी बदल जाती है
  • मौजूदा branch protection, required checks, और merge requirements लागू रहते हैं, जिससे main में जाने वाले बदलावों पर नियंत्रण बना रहता है
  • पूरे stack के साथ-साथ किसी एक layer या कुछ selected layers को भी selectively merge किया जा सकता है

public preview और support timeline

  • Stacked pull requests को आने वाले कुछ दिनों में सभी repositories में public preview के रूप में चरणबद्ध rollout किया जाएगा
  • Merge queue support अगले कुछ हफ्तों में धीरे-धीरे rollout होगा
  • इस्तेमाल की विस्तृत जानकारी stacked pull requests documentation में देखी जा सकती है, और stacks discussion में feedback लिया जा रहा है

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News टिप्पणियाँ

  • मैंने प्रीव्यू कुछ समय इस्तेमाल किया, और हैरानी इस बात की है कि इतने अनसुलझे मुद्दों के बावजूद इसे व्यापक रूप से जारी किया जा रहा है
    उदाहरण के लिए, पूरे स्टैक को merge करना कई स्थितियों में पूरी तरह टूट जाता है: https://github.com/github/gh-stack/discussions/212
    इन्हें एक-एक करके merge किया जा सकता है, लेकिन squash merge और required review साथ इस्तेमाल करने पर स्टैक के हर PR के लिए फिर से approval लेना पड़ता है, जिससे stacked PR का सबसे बड़ा फ़ायदा खत्म हो जाता है
    gh stack थोड़ा manual काम कम करता है, लेकिन फिर भी git rebase को ठीक से समझना ज़रूरी है. अगर local branch remote के साथ sync में नहीं है, तो UI द्वारा सुझाया गया gh stack rebase भी fail हो जाता है, और tool यह नहीं बताता कि कारण क्या है
    दूसरी ओर, stack UI सरल है और PRs के बीच संबंधों को काफ़ी अच्छी तरह दिखाता है, इसलिए यह पसंद आया. यह केवल workflow को आसान बनाता है, इस मान्यता पर कि PRs को stack करने की वजह पहले से मौजूद है; यह कोई नई capability देने वाला tool नहीं है

    • squash merge समस्या को हल करने वाले bug fixes क्रमिक रूप से deploy किए जा रहे हैं
      अंदरूनी CPRMC(Create Pull Request Merge Commit) conflict होने की संभावना से लेकर इस बात तक जांचता है कि approvals वास्तव में बनने वाले commit से मेल खाते हैं या नहीं, ताकि यह तय किया जा सके कि PR merge के लिए तैयार है या नहीं
      कई PRs को squash merge करने के लिए लगातार squash commits की गणना करनी पड़ती है और फिर उन्हें rules और reviews से दोबारा जोड़ना पड़ता है. पहला PR अपेक्षाकृत आसान है, लेकिन दूसरे से जटिलता बढ़ जाती है क्योंकि ancestor commits squash हो चुके होते हैं और branch में अपने मूल रूप में मौजूद नहीं रहते, और जिन स्थितियों में कई parents हों वे और भी कठिन हैं
      अभी stack merge का 99% सफल हो रहा है, लेकिन इसे और बहुत ऊपर ले जाना टीम की सर्वोच्च प्राथमिकता है
    • आज stacked PR जिस branch की ओर इशारा कर रहा था, उसे delete करने पर मुझे एक bug मिला जिसमें वह बिना किसी अतिरिक्त सूचना के merging स्थिति में अटका रहा
      मुझे लगा PR system में partial outage है, इसलिए मैंने GitHub status page तक देख लिया, लेकिन यह stacked PR feature का ही bug निकला
    • लगता है 2021 के बाद से पूरी industry पूरी तरह ready, fire, aim वाले तरीके पर आ गई है
    • हमारी कंपनी में भी हाल में इस feature और merge queue की वजह से बहुत समस्याएँ हुईं

  • GitHub Stacked PRs टीम अब इसे अधिक व्यापक रूप से उपलब्ध करा रही है ताकि कोई भी stack बना सके: https://gh.io/stacks
    वे खास तौर पर UI और CLI पर feedback चाहते हैं, और PR इस्तेमाल के अनुभव को बेहतर बनाने के लिए कई updates भी तैयार कर रहे हैं
    यह GitHub के इतिहास की सबसे बड़ी releases में से एक है, क्योंकि यह Actions और protection rules से लेकर CLI और mobile app तक लगभग हर service को छूती है, इसलिए design decisions और internal workings पर सवालों के जवाब भी दिए जा सकते हैं

    • आज पहली बार इसे आज़माया और परिणाम पसंद आया
      मैं पहले से अपने local UI में stacked PR dependencies को tree के रूप में देखता हूँ और हर PR की review/CI status manage करता हूँ, इसलिए अच्छा होगा अगर GitHub web UI में भी tree और status display हो
      web UI में शायद stack के सबसे नीचे वाले PR को ही merge करने की सुविधा नहीं है, लेकिन चूँकि existing workflow और code साझा किए जा सकते हैं, उम्मीद है यह GitHub के default tools में भी आएगा
    • जानना चाहता हूँ कि क्या निकट भविष्य में forks के पार stacked PRs को support करने की योजना है
      public repositories में उपयोगी होने के लिए यह एक महत्वपूर्ण feature लगता है, इसलिए हैरानी है कि इसे public preview से पहले उपलब्ध नहीं कराया गया
    • Gerrit की जिन चीज़ों की मुझे सबसे ज़्यादा कमी महसूस होती थी, यह वही है
    • यह जानने की उत्सुकता है कि work breakdown की इकाई के रूप में अतिरिक्त PRs क्यों चुने गए
      commits के आधार पर review/apply/edit करने वाली एक सही UI की बजाय, क्या इस approach की मूल प्रेरणा mailing list के patch series workflow को नज़रअंदाज़ करके लगभग 'patch series की series' चुनने के पीछे कोई खास insight थी

  • पिछले कई वर्षों में GitHub पर लागू हुए बदलावों में यह सबसे बड़े बदलावों में से एक है
    दुनिया के सबसे बड़े code hosting platforms में से एक में stacked workflow आने से बहुत से developers ऐसे तरीके से परिचित हो सकते हैं जिसके अस्तित्व के बारे में भी वे पहले नहीं जानते थे
    अगर यह मान्यता सही है कि stacks बेहतर software बनाते हैं, तो इससे वास्तव में बहुत से developers को मदद मिल सकती है

  • मैं जानना चाहता हूँ कि अच्छी तरह व्यवस्थित commits को commit-दर-commit review करने की तुलना में ऐसे stacked PRs के फ़ायदे क्या हैं
    इससे भी बड़ा मुद्दा यह है कि बड़े AI-generated PRs के लिए शायद एक अलग review method की ज़रूरत है. जैसे function definition changes, call sites, और tests के क्रम में दिखाना—सिर्फ diff दिखाने का क्रम ही पठनीयता में बहुत बड़ा फ़र्क ला सकता है
    जैसे literate programming code और गद्य को जोड़ती है, वैसे ही diff और explanation को जोड़ने वाले literate diff या literate PR की ज़रूरत हो सकती है, लेकिन मुझे अभी तक ऐसा कोई tool नहीं मिला

    • Phabricator आदि में stacked diffs इस्तेमाल करने वालों के लिए, यही तो अच्छी तरह व्यवस्थित commits को एक-एक करके review करने का तरीका है
      क्योंकि review unit यानी PR या diff एक सीमित बदलाव के रूप में बना रहता है, चर्चा उसी बदलाव पर केंद्रित रहती है, और feature बड़ा हो जाने पर भी PR खुद बहुत बड़ा नहीं होता
      साथ ही, stack के अलग-अलग हिस्सों को अलग targets को सौंपा जा सकता है. जैसे external teams, उसी team के सहकर्मी, या बदलाव का उपयोग करने वाली teams—इस तरह reviewers को बाँटा जाए तो किसे किस चीज़ की approval देनी है, यह अस्पष्ट नहीं रहता
      अगर GitHub review में change ID आ जाए ताकि rebase के बाद भी comments बने रहें, तो और भी अच्छा होगा
    • अगर stack के पहले PR में commit जोड़ा जाए, तो उसे पूरे commit क्रम के बीच में डाला जा सकता है
      उसके बाद PRs को rebase और edit करना पड़ता है, जो किसी बड़े single PR के बाद के commits को ठीक करने जैसा ही है, लेकिन पूरे बदलाव पर इधर-उधर अस्थायी fix commits चिपकाने के बजाय आधारभूत बदलाव के commits को साथ रखना आसान हो जाता है
      आधारभूत बदलाव पर चर्चा भी साथ में इकट्ठी रहती है, और अगर पूरा stack पहले से दिखा दिया जाए तो reviewer अंतिम दिशा समझ सकता है जबकि काम asynchronous तरीके से चलता रह सकता है
    • असली बात यह है कि वास्तव में 'अच्छी तरह व्यवस्थित' commits बनाने वाले लोग बहुत कम हैं
      लोग commits को game save points की तरह इस्तेमाल करते हैं, fix bug, do work जैसे messages छोड़ते हैं, और git rebase -i से उन्हें साफ़ नहीं करते, इसलिए अगर required squash merge चालू न हो तो log बेकार commits से भर जाता है
      ऐसे developers के लिए PR ही commit है, और stacked PRs के ज़रिए वे पहली बार एक ऐसे ढाँचे का उपयोग कर पाते हैं जो एक बदलाव बनाने वाले कई commits जैसा दिखता है
    • stack का उपयोग करने पर लंबे बदलाव वाले काम को जारी रखते हुए भी लगातार review करने लायक आकार के diffs बनाए जा सकते हैं
      merged diffs को मौजूदा HEAD के ऊपर rebase किया जा सकता है, और जो teams इसे support करती हैं वे आमतौर पर branches को सीधे manage नहीं करतीं बल्कि trunk पर काम करती हैं और हर नए बदलाव के आने पर rebase करती हैं
    • PR में commits को एक-एक करके merge नहीं किया जा सकता, लेकिन stack में यह संभव है
      अगर feature के शुरुआती 4 हिस्से तैयार हों और 5वें में समस्या हो, तो पूरे काम को रोकने की ज़रूरत नहीं होती

  • यह जानने की जिज्ञासा है कि निर्भरता वाले PR अगर रैखिक इतिहास के बजाय tree structure बनाते हों, तो उसका समर्थन कब मिलेगा
    Google में stacked changes इस्तेमाल करते समय ऐसे मामले आम थे, और अब parallel coding agents बढ़ने के साथ यह और भी ज़्यादा आम हो सकते हैं

    • यह ऐसी संरचना है जिसे इंसानों के लिए भी संभालना मुश्किल है, इसलिए यह संदेह है कि सॉफ़्टवेयर और उससे जुड़े AI को वास्तव में इस तरह के तरीके को बढ़ावा देना चाहिए या नहीं

  • यह जानने की जिज्ञासा है कि menu toggle button का pancake stack emoji (U+1F95E) stack feature की वजह से है या नहीं
    मज़ाकिया अभिव्यक्ति अपने आप में ठीक है, लेकिन यह ऐसा UI था जो इस बात पर गहरा संदेह पैदा करता था कि आखिर हम क्या देख रहे हैं

    • अंदरूनी तौर पर pancake emoji इस्तेमाल किया गया था और उसे एक मज़ेदार easter egg की तरह डाला गया था
      इसे कुछ घंटों के लिए ही दिखाने के बाद सामान्य icon पर वापस ले जाने की योजना है
    • सही है: https://github.com/orgs/community/discussions/203497

  • मैंने पहली बार खबर सुनने के समय से ही gh stack CLI इस्तेमाल किया था, और टूल खुद बहुत अच्छा था, लेकिन preview approval मिलने के बाद जो web UI देखा, वह उम्मीदों से काफी कम निकला
    approval से पहले भी CLI काम को कई atomic PRs में बाँटने की automation आसानी से देता था, लेकिन push करने पर वे एक-दूसरे से जुड़े हुए नहीं बल्कि स्वतंत्र PRs की तरह दिखते थे
    approval के बाद भी लगभग वही स्थिति है; ऊपर वाले छोटे navigation dropdown में सिर्फ उसी stack के दूसरे PRs दिखते हैं, इसलिए कोई अर्थपूर्ण UI बदलाव नहीं है
    dropdown से CLI की कुछ सुविधाएँ की जा सकती हैं, लेकिन वे web पर files edit करने जैसी सहायक सुविधा के अधिक करीब हैं, और वास्तविक development workflow में CLI या IDE plugin ही केंद्र में रहेंगे
    इतनी-सी वैकल्पिक UI सुविधा के लिए सामान्य सार्वजनिक उपलब्धता को इतने लंबे समय तक क्यों टाला गया, यह सवाल है; stack CLI तो घोषणा के समय से ही पहले से सामान्य रूप से उपलब्ध था

    • शुरुआत minimal functionality से करनी पड़ी, लेकिन अब कहीं अधिक व्यापक PR UI revamp पर काम चल रहा है
      इसमें ऐसे views भी शामिल होंगे जो stack को लगातार दिखाएँगे ताकि हर स्तर के बीच जाने के लिए बहुत ज़्यादा click न करना पड़े और stack के प्रति हमेशा जागरूकता बनी रहे

  • jujutsu की अच्छी बात यह है कि branch को अपडेट करने पर उसी branch से निकली दूसरी branches भी अपने-आप rebase हो जाती हैं
    review आसान बनाने के लिए काम बाँटते समय मैं अक्सर jj पर स्विच करता हूँ, और Git से बने clone के साथ उसी working directory में साथ-साथ इस्तेमाल करने पर भी यह अच्छी तरह काम करता है

    • jj absorb भी शानदार है
      यह बदलावों को सबसे नज़दीकी संबंधित change में ले जाता है, इसलिए कई PRs को प्रभावित करने वाले fixes भी आसानी से संभाले जा सकते हैं

  • Graphite इस्तेमाल करने के बाद stacked PRs के बिना GitHub पर लौटना बहुत मुश्किल हो गया
    उम्मीद है कि GitHub के समर्थन से stacked PR workflow आम हो जाएगा और विशाल PRs के बजाय एक आसान विकल्प मिलेगा

    • git-spice की सिफारिश करता हूँ
      यह इस्तेमाल में आसान और शक्तिशाली open source है, जबकि Graphite अपनी सुविधाओं की तुलना में अनावश्यक रूप से जटिल लगा

  • मेरी समझ में PR stacking दो स्थितियों में उपयोगी है
    पहली, जब काम कई संबंधित repositories में फैला हो और उसे एक ही PR में जोड़ा न जा सके; दूसरी, जब पहले PR के review के दौरान उसी branch के ऊपर आगे के PRs stack करके काम को pipeline किया जाए
    लेकिन यह सुविधा इन दोनों में से किसी को भी पूरा नहीं करती, बल्कि एक ही PR पर commits stack करने के एक और रूप जैसी लगती है
    आम तौर पर atomic और सार्थक commits बनाए जा सकते हैं, फिर rebase के ज़रिए ऐसा flow बनाया जा सकता है जिसे reviewer आसानी से समझ सके, और reviewer चाहे तो commit-दर-commit भी देख सकता है
    यह जानने की जिज्ञासा है कि इस तरीके में ऐसा कौन-सा अनूठा लाभ है जो मेरी नज़र से छूट रहा है