Evan का Jujutsu ट्यूटोरियल

 (evmar.github.io)
1 पॉइंट द्वारा GN⁺ 12 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Git का उपयोग करने का अनुभव रखने वाले पाठकों के लिए सरल लेकिन शक्तिशाली version control system Jujutsu(jj) को संक्षेप में सीखने के लिए तैयार किया गया ट्यूटोरियल
  • सीखना शुरू करने से पहले Jujutsu का उपयोग क्यों करें, यह जानने के इच्छुक पाठकों के लिए अलग Jujutsu परिचय लेख भी दिया गया है
  • संवादात्मक शुरुआती गाइड, विस्तारपूर्ण आधिकारिक दस्तावेज़, version control के बिल्कुल नए पाठकों के लिए सामग्री आदि जैसे पाठक के स्तर के अनुसार विकल्प भी बताए गए हैं
  • विषयों के चयन, किन बातों को छोड़ा जाए, और किस क्रम में रखा जाए, यह सावधानी से तय करने के लिए इसे Evan Martin ने स्वयं लिखा है
  • मुख्य लेखन में AI का उपयोग नहीं किया गया, और अधिकांश सामग्री पूरी होने के बाद सिर्फ त्रुटि जाँच के लिए AI का उपयोग किया गया

लक्षित पाठक और सीखने का मार्ग

  • Jujutsu एक सरल लेकिन शक्तिशाली version control system है, और इस ट्यूटोरियल में आगे इसे jj के रूप में लिखा गया है
  • यह Git से परिचित पाठकों के लिए मुख्य बातों पर केंद्रित एक संक्षिप्त सीखने का प्रवाह प्रदान करता है
  • अगर आप तुरंत सीखना शुरू करना चाहते हैं, तो ट्यूटोरियल शुरू करें पर जा सकते हैं; और अगर आप पहले इसकी ज़रूरत समझना चाहते हैं, तो Jujutsu परिचय लेख देख सकते हैं

पाठक के अनुसार वैकल्पिक सामग्री

  • अगर इस ट्यूटोरियल का तरीका आपके लिए उपयुक्त नहीं है, तो अपने अनुभव स्तर और पसंद के अनुसार नीचे दी गई सामग्री चुन सकते हैं
    • Steve's Jujutsu tutorial: शुरुआती लोगों के लिए सबसे अधिक अनुशंसित सामग्री, संवादात्मक शैली में लिखी गई है
    • Jujutsu documentation: एक आधिकारिक ट्यूटोरियल प्रदान करता है जो शुरुआत से ही अधिक विस्तार में जाता है
    • Jujutsu for Everyone: उन पाठकों के लिए है जिनके पास पहले से version control का अनुभव नहीं है

स्वयं लेखन और AI के उपयोग की सीमा

  • पूरा पाठ Evan Martin ने स्वयं लिखा है, और क्या शामिल करना है, क्या छोड़ना है, तथा किस क्रम में रखना है, यह सब मनुष्य द्वारा सावधानी से तय किया गया है
  • मुख्य सामग्री लिखने में AI का उपयोग नहीं किया गया, और अधिकांश लेखन पूरा होने के बाद केवल त्रुटियों की जाँच के लिए इसका उपयोग किया गया

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

1 टिप्पणियां

 
GN⁺ 12 시간 전
Lobste.rs की राय

  • सच कहूँ तो अपनी साख दाँव पर लगाकर कह सकता हूँ कि मैंने करीब एक हफ्ते jj इस्तेमाल किया, लेकिन आखिरकार Git को सीधे संभालने की तकलीफ़ कम करने के लिए LLM की मदद लेनी पड़ी, और यह भी नहीं लगा कि यह मेरे मौजूदा workflow की पूरी तरह जगह लेता है
    मैं आम तौर पर सिर्फ git checkout, git add, git commit, git push ही इस्तेमाल करता हूँ, और प्रचार लेखों में जिन index, stash, कई तरह के reset, बीच में चल रहे rebase, और असंगत undo जैसी समस्याओं की बात होती है, उनसे मेरा लगभग कभी सामना नहीं हुआ; मैं monorepo भी ज़्यादा इस्तेमाल नहीं करता
    Jujutsu का मुख्य target user कौन है, और jj में निपुण होने में कितना समय लगा—यह जानने में दिलचस्पी है; अगली बार कम से कम उतना समय तो देना चाहूँगा

    • आप LLM से खास तौर पर किस तरह के काम में मदद माँगते हैं, यह जानना चाहूँगा
      मैं भी Git में बुनियादी कामों से आगे बढ़ने से बचता हूँ; stash करके branch बदलने की बजाय मैंने repo को दूसरी जगह फिर से clone किया, और सिर्फ संबंधित बदलाव चुनकर commit करने की बजाय git add --all से सब कुछ commit कर दिया, या editor में बदलाव revert करके commit किया और फिर दोबारा apply किया
      नौकरी में 7 साल Mercurial इस्तेमाल करने की वजह से jj अपनाना मेरे लिए आसान रहा, लेकिन अब commit को इधर-उधर रखना और कई बदलावों को संभालना इतना आसान हो गया है कि पहले जिन जटिल कामों से मैं सहज रूप से बच निकलता, अब उन्हें सक्रिय रूप से करता हूँ
    • आप version control system (VCS) का इस्तेमाल किस उद्देश्य से करते हैं, इस पर नज़रिया बदलता है
      अगर आप बस linearly development करते हैं और कभी-कभार snapshot छोड़ना चाहते हैं, तो वे commands काफी हैं, और पूरा VCS ज़रूरत से ज़्यादा भी हो सकता है—Dropbox ही काफी हो सकता है
      मेरे लिए VCS कोड और उसकी परतों के बारे में मेरी सोच को दिखाने वाला narrative बनाने का tool है; इसका मुख्य पाठक सहकर्मी हैं और दूसरा पाठक 10 साल बाद का मैं हूँ। jj इसे बहुत कम friction के साथ संभव बनाता है
    • LLM से मदद माँगना बिल्कुल ठीक है; मैंने भी ज़रूरी basic commands सीखने तक ऐसा ही किया
      terminology और features की बुनियाद समझने के लिए मैंने कुछ guides शुरू से अंत तक पढ़ीं, और कुछ दिनों तक इसे अपने personal project में लगातार इस्तेमाल करने के बाद basic कामों में काफ़ी सहज हो गया; VCS को देखने का मेरा तरीका भी बदल गया
      refactoring या बड़े feature पर काम करते समय मैं पहले अंतिम लक्ष्य तक implementation पूरा करता हूँ, फिर उसे ऐसे छोटे बदलावों में बाँटता हूँ जिन्हें review करना आसान हो और जिनका कारण साफ़ हो—जैसे “सभी eslint warnings ठीक करना”, “function expose करने के लिए refactoring”, “call site A को नए function में बदलना”, “नया feature जोड़ना”। jj split इस काम के लिए बिल्कुल perfect है, और सिर्फ यह एक feature भी jj इस्तेमाल करने के लिए काफ़ी वजह है
      इसके उलट git stash में कई stash संभालना मुश्किल है, और conflict होने पर save किया हुआ कोड खोने का जोखिम भी रहता है—यह usability traps से भरा है। नीचे वाले commit पर PR feedback लागू करके ऊपर के commit या PR को rebase करना भी, खासकर stacked PR में, progress indicator न होने, बीच में रुक जाने, या दोबारा stack बनाना कठिन होने की वजह से लगभग डरावना अनुभव है। इसलिए stacked PR management के लिए मैं अब भी Graphite इस्तेमाल करता हूँ
    • jj से मुझे सबसे बड़ा फायदा rebase को संभालने के तरीके में मिला
      organic chemistry में graduate student रहे एक व्यक्ति ने paper work branch को 4 साल तक बिना merge या rebase किए विकसित किया था, जिससे वह main से हजारों commits पीछे रह गई; degree review से पहले उसे merge करना था। लगभग हर commit पर conflict आता था, इसलिए Git में इसमें 1–2 हफ्ते लगते; और अगर तीसरे दिन कोई urgent bug आ जाए, तो rebase रोककर bug fix करना पड़ता और फिर शुरुआत से फिर चालू करना पड़ता। 3 हफ्ते बाद जब काम खत्म हुआ, तब latest main के हिसाब से फिर rebase करना पड़ा
      jj में merge conflicts first-class object हैं, इसलिए समय मिलने पर उन्हें resolve किया जा सकता है, और बीच में नए commit पर जाकर urgent bug ठीक करने पर भी progress नहीं खोती। Git में जो rebase एक हफ्ता लेता, वह एक दिन में पूरा हो गया; एक बार तो लगातार 200 ऐसे commits मिल गए जिन्हें merge करने पर कोई बदलाव ही नहीं होता था, और मैं जिन टकरावों की दसियों हज़ार lines को दो दिन से संभाल रहा था, उन्हें एक मिनट से भी कम में पूरा का पूरा फेंक सका। Rebase के दौरान भी main अपडेट किया जा सकता है और काम वाली branch को latest main के ऊपर ले जाया जा सकता है

  • मैं Git का इतना आदी हूँ कि कभी-कभी बस command देखनी पड़ती है, फिर भी यह लेख पहला Jujutsu परिचय लेख है जो मुझे सच में दिलचस्प लगा
    पहले के लेख ज़्यादातर “आप भयानक Git command-line interface से निकल सकते हैं” से शुरू होते थे; मैं Git की विचित्रताओं और दूसरों की दिक्कतों को समझता हूँ, लेकिन ऐसी भाषा की वजह से Jujutsu मुझे romance novel या beef vindaloo की तरह कोई ऐसी चीज़ लगती थी जिसका मुझसे लेना-देना नहीं

    • jj की खुशी समझाना मुश्किल इसलिए है क्योंकि कई implicit properties, जिन्हें मैं हर VCS में स्वाभाविक मानता था, दरअसल वैसी नहीं हैं, और atomic operations कहीं ज़्यादा सरल हैं
      अच्छा marketing phrase बनाना कठिन है, इसलिए आखिर में “यह Git नहीं है” ही पूरी व्याख्या बन जाती है; मैं खुद भी इसे ठीक से समझाने में अच्छा नहीं हूँ
    • Git में Sublime Merge GUI और कुछ custom commands का इस्तेमाल करके यहाँ बताई गई लगभग सारी समस्याएँ हल की जा सकती हैं
      दूसरे Git GUI से अलग, यह असली Git commands के क़रीब से क़रीब रहता है, बस कठिन syntax को menus और buttons में बदल देता है, और हर action से जुड़ी command को छिपाने की बजाय status bar में दर्ज भी करता है। अगर Sublime JJ आया, तो मैं तुरंत उस पर चला जाऊँगा
    • जिस अभिव्यक्ति ने मुझे jj आज़माने का मन कराया, वह थी: Git जो हमेशा interactive rebase की स्थिति में हो