सभी के लिए Jujutsu

 (jj-for-everyone.github.io)
2 पॉइंट द्वारा GN⁺ 2025-09-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह दस्तावेज़ एक शुरुआती ट्यूटोरियल है, जो Git का अनुभव न होने पर भी Jujutsu(VCS) को चरणबद्ध लेवल संरचना में सिखाता है
  • यह टर्मिनल के उपयोग को आधार मानता है, लेकिन टर्मिनल की बुनियाद से शुरू करता है; मुख्य कमांड्स को Linux/macOS केंद्रित रूप में समझाया गया है और Windows उपयोगकर्ताओं के लिए WSL की सिफारिश की गई है
  • सीखने का प्रवाह लेवल 1~3 में बुनियादी बातें·सहयोग·समस्या समाधान को मजबूत करता है, और ऊपरी लेवल में history rewrite·advanced workflow तक विस्तार करता है
  • ट्यूटोरियल के दौरान स्थिति गड़बड़ा जाने पर, हर अध्याय की शुरुआती अवस्था में लौटाने के लिए reset script के साथ पुनरुत्पादित किया जा सकने वाला सीखने का वातावरण दिया गया है
  • Git की जगह Jujutsu क्यों, इसके लिए Git compatibility, सीखने की कठिनाई में कमी, और advanced functionality को आधार के रूप में रखा गया है; और सामग्री को नवीनतम Jujutsu 0.32 के अनुसार अपडेट किया जा रहा है

परिचय(Introduction)

  • यह ट्यूटोरियल उन उपयोगकर्ताओं के लिए प्रारंभिक सामग्री है जो पहली बार Jujutsu इस्तेमाल कर रहे हैं
  • मौजूदा Jujutsu सामग्री की उस सीमा को पूरा करने के लिए, जो अनुभवी Git उपयोगकर्ताओं के migration पर केंद्रित रही है, यह beginner-centered सामग्री प्रदान करता है
  • टर्मिनल का उपयोग आधारभूत है, और इसमें बेसिक टर्मिनल उपयोग का अध्याय शामिल है; Windows उपयोगकर्ताओं को WSL इस्तेमाल करने की सलाह दी जाती है

पढ़ने का तरीका(How to read this tutorial)

  • सामग्री लेवल इकाइयों में व्यवस्थित है, और हर लेवल पूरा करने के बाद वास्तव में अभ्यास करके फिर अगले लेवल पर जाने के लिए सीखने की रूपरेखा बनाई गई है
  • यदि आपका उद्देश्य collaboration है, तो लेवल 1 और 2 को लगातार पढ़ने की सिफारिश की जाती है
  • लेवल का अवलोकन
    • लेवल 1: व्यक्तिगत काम के लिए ज़रूरी न्यूनतम शुरुआती सेट देता है; अकेले असाइनमेंट संभालने वाले छात्र के स्तर के लिए उपयुक्त
    • लेवल 2: सहयोग के लिए न्यूनतम सेट, जो छात्र team project और कामकाजी डेवलपर्स के लिए आवश्यक है
    • लेवल 3: conflict resolution, recovery जैसी समस्या-समाधान की बुनियाद; औसत डेवलपर कौशल-स्तर के अनुरूप
    • लेवल 4: history rewrite के जरिए साफ-सुथरा इतिहास बनाना; कुछ प्रोजेक्ट्स के quality standard पूरे करने के लिए आवश्यक
    • लेवल 5: productivity booster·advanced workflow·sparse CLI·theory, Jujutsu master स्तर
    • लेवल 6: tag·submodule·workspace जैसे परिस्थिति-आधारित विषय; ज़रूरत पड़ने पर संदर्भ के रूप में उपयोग की सिफारिश

शॉर्टकट कुंजियाँ(Keyboard shortcuts)

  • बाएँ-दाएँ arrow keys से अध्यायों के बीच नेविगेशन समर्थित है
  • S या / से पुस्तक के भीतर खोज की जा सकती है
  • ? से help दिखाई जाती है, और Esc से छिपाई जा सकती है

अपनी प्रगति रीसेट करें(Reset your progress)

  • उदाहरण repository की स्थिति अगले अध्याय से जुड़ी होती है, इसलिए स्थिति खो जाने पर आगे बढ़ना रुक सकता है
  • इसे हल करने के लिए, अध्याय की शुरुआती अवस्था में बहाल करने वाला reset.sh script दिया गया है
  • हर अध्याय की शुरुआत में सटीक reset command शामिल है, ताकि copy-paste से पुनरुत्पादन किया जा सके
  • script चलाने से पहले उसकी सामग्री की समीक्षा करने की सिफारिश की जाती है; व्यवहार में यह मैनुअल कमांड्स के संग्रह जैसी सरल क्रिया करता है
  • script की मुख्य विशेषताएँ
    • JJ_CONFIG=/dev/null के जरिए user settings के प्रभाव को रोका जाता है
    • उदाहरण repo बनाना, colocate Git integration, user info सेट करना, commit/push/fetch/rebase जैसी लगातार scenarios को फिर से बनाना
    • हर chapter keyword को argument के रूप में लेकर, उसी बिंदु पर सफलतापूर्वक समाप्त होने के लिए branching design

नवीनतम बने रहें(Stay up to date)

  • ट्यूटोरियल और Jujutsu दोनों लगातार विकसित हो रहे हैं, और ट्यूटोरियल repository की Releases subscribe करके बड़े बदलावों की सूचना मिल सकती है
  • इसमें स्पष्ट कहा गया है कि यह ट्यूटोरियल Jujutsu 0.32 के मानक पर (अगस्त 2025) के अनुसार नवीनतम है
  • GitHub में Watch → Custom → Releases के जरिए update notifications सेट करने का निर्देश दिया गया है

version control की ज़रूरत(What is version control and why use it?)

  • यह केवल software ही नहीं बल्कि Typst जैसी दस्तावेज़-लेखन के लिए भी लागू होने वाला क्रमिक कार्य-संचय प्रबंधन का साधन है
  • यह पिछली स्थिति में वापस लौटने की क्षमता देता है और कई लोगों के एक साथ काम को सुरक्षित रूप से समर्थन देता है
  • सामान्य backup या collaboration editor की तुलना में जब ज़्यादा बारीक नियंत्रण वाले tools की ज़रूरत हो, तब Jujutsu उपयुक्त है

Jujutsu क्यों(Why Jujutsu instead of Git?)

  • Git compatibility: मौजूदा Git repositories के साथ बिना नुकसान के interoperability, और अधिकतर Git integration tools का वैसा ही उपयोग संभव
  • सीखने में आसानी: Git के जटिल और कम सहज UI की तुलना में Jujutsu वही सुविधाएँ कम जटिलता के साथ देता है
  • और अधिक शक्तिशाली functionality: आसान सीखने से अलग, यह power user features की बड़ी संख्या देता है, जिससे workflow scalability सुनिश्चित होती है
  • कमियाँ और विचारणीय बातें
    • बातचीत के दौरान Git terminology-केंद्रित संस्कृति के साथ concept mapping का बोझ रहता है, जिसे सहकर्मियों को समझाकर कुछ हद तक कम किया जा सकता है
    • अपेक्षाकृत नया होने के कारण Git की कुछ सुविधाएँ शामिल न होने के मामले हैं; ज़रूरत पड़ने पर सीधे Git इस्तेमाल करके fallback किया जा सकता है
    • CLI अभी भी stabilization process में है, इसलिए कुछ कमांड बदल सकते हैं; बदलावों को ट्रैक करने के लिए ट्यूटोरियल की release subscription की सिफारिश की जाती है

सीखने की प्रगति(Completed & Next)

  • अभी सामग्री लेवल 1~3 केंद्रित है, ताकि व्यावहारिक कार्य-प्रवाह (installation→initialization→log/commit→remote/push·clone→branch/merge→rebase→navigation→undo/recovery→conflict resolution→cleanup) को अच्छी तरह सीखा जा सके
  • ऊपरी लेवल में rewrite·advanced workflow·sparse topics को जोड़कर क्रमिक दक्षता रणनीति प्रस्तुत की गई है

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

1 टिप्पणियां

 
GN⁺ 2025-09-01
Hacker News राय

  • ऐसा लगता है कि मैंने jj की तारीफ़ करने वाले दर्जनों लेख देखे हैं। यह ट्यूटोरियल भी कुछ वैसा ही है, लेकिन अब इसके अच्छे पहलुओं के बारे में काफ़ी पढ़ लिया है, इसलिए इसकी कमियों और असुविधाओं में ज़्यादा रुचि है। मैंने jj इस्तेमाल किया है, और इसके फ़ायदे-नुकसान दोनों मिले। मैं अक्सर ऐसा workflow इस्तेमाल करता हूँ जहाँ सहकर्मियों के साथ branch साझा करके commits जोड़ते रहते हैं, लेकिन jj में named branches न होने की वजह से यह git की तुलना में ज़्यादा झंझटभरा लगा (tug alias के साथ भी)। ट्यूटोरियल का “Tracking remote bookmarks” सेक्शन भी मुझे अब भी असुविधाजनक लगता है। एक और परेशानी यह थी कि jj में git clone --filter=blob:none जैसा light clone इस्तेमाल नहीं कर सकता था; जानना चाहता हूँ कि क्या यह अब ठीक हुआ है

    • jj में named branches हैं, बस jj में उन्हें “bookmarks” कहा जाता है। अगर remote bookmark को track करें, तो jj git fetch से local remote के साथ sync हो जाता है

    • जिन बातों ने मुझे परेशान किया उनमें एक यह थी कि कभी-कभी jj मेरे changes को जैसे अचानक खो देता था। मैं Cursor में काम कर रहा होता था और jj से repo को mutate नहीं कर रहा था (jj status, jj log जैसी चीज़ें ही चला रहा था), लेकिन बाद में देखता तो changes ग़ायब होते थे, और अक्सर "stale workspace" संदेश भी दिखता था। पता नहीं यह IDE की वजह से था या किसी बहुत बड़े monorepo की वजह से, लेकिन सच में काफ़ी दर्दनाक था। फिर भी, jj की flexibility मुझे काफ़ी पसंद है

    • https://github.com/jj-vcs/jj/discussions/3549 में tug workflow को थोड़ा और सरल बनाने पर चर्चा है

    • यह कहना ग़लत है कि jj में named branches नहीं हैं। jj branch set -r@ XYZ की तरह इसे manually सेट करना पड़ता है, इसलिए थोड़ा असुविधाजनक ज़रूर है, लेकिन push करते समय एक बार ही करना होता है। या फिर jj git push --named XYZ=@ से branch को move भी किया जा सकता है

    • jj अब भी light clone (git clone --filter=blob:none) को support नहीं करता

  • कहा गया है कि “Jujutsu Git से ज़्यादा powerful है”, लेकिन किस मायने में powerful है, इसकी कोई ठोस व्याख्या नहीं है, इसलिए समझ नहीं आता कि इसे क्यों इस्तेमाल करें। यह बस एक आकर्षक वाक्य जैसा लगता है

    • मैं ट्यूटोरियल का लेखक हूँ। क्योंकि यह शुरुआती लोगों के लिए था, Git के साथ विस्तृत तुलना करना उपयुक्त नहीं था। Git UI की जटिलता को अक्सर उसकी “power” से justify किया जाता है, इसलिए मैं बस यह जोड़ना चाहता था कि Jujutsu सीखने में आसान होने का मतलब यह नहीं कि users कोई functionality खो रहे हैं

    • उदाहरण के लिए, आपने Main branch से एक नई branch बनाई और बाद में उसे PR के रूप में भेजने का इरादा है। आप कई commits जोड़ते जाते हैं, लेकिन फिर लगता है कि commit 1 बदलना चाहिए। ऐसे में commit 1 को edit करके save कर दें, बाकी सारे commits अपने-आप नए state पर rebase हो जाते हैं। PR के बाद भी अगर commit 3 बदलना हो, तो बस उसी commit को edit करके push कर दें। Git में यह सब सीधे करना सच में बहुत मुश्किल है। मेरे सहकर्मियों को कई commits में बँटे PR बहुत पसंद हैं

    • मैं भी कुछ हद तक यही सोचता हूँ। मुझे लगता है कि Git UI कुल मिलाकर काफ़ी कमज़ोर हैं, इसलिए मैं jj को कुछ हद तक भरोसे के साथ इस्तेमाल करने को तैयार हूँ। लेकिन “यह ज़्यादा आसान, powerful या convenient क्यों है” इसका कोई ठोस demo होता तो और अच्छा रहता

    • एक उदाहरण यह है कि merge conflict को एक item के रूप में दर्ज करके बाद में निपटाया जा सकता है: https://jj-vcs.github.io/jj/latest/conflicts/

  • मैंने हाल में JJ को फिर से आज़माया, और यह काफ़ी बेहतर हो चुका है, इसलिए मज़े से इस्तेमाल कर रहा हूँ। जब शुरू में आज़माया था, तब इसमें बहुत से rough edges थे, इसलिए अपनाने में झिझक होती थी; लेकिन मुझे लगता है कि JJ हाल के शानदार tooling की “नई लहर” का हिस्सा है। मैंने अपने ब्लॉग पर भी इसके बारे में लिखा है: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

    • बढ़िया लेख है। मुझे लगता है कि पिछले कुछ वर्षों में developer tooling का स्तर सच में बहुत ऊपर गया है। Rust भी उसी बदलाव का हिस्सा है

    • यह जानकर अच्छा लगा कि आप भी mise इस्तेमाल करते हैं और पसंद करते हैं। mise, jj (और पूरी तरह शानदार jjui TUI), और Python के लिए uv—सब बेहद क्रांतिकारी हैं। मुझे ये tools सच में सुंदर लगते हैं

    • मैं इसमें nushell को भी ज़रूर जोड़ना चाहूँगा

    • Bun भी इस tooling innovation की अग्रिम पंक्ति में है

  • शानदार काम! मैं लगभग 5 महीनों से सिर्फ़ Jujutsu इस्तेमाल कर रहा हूँ और इसने git को पूरी तरह replace कर दिया है। इस दौरान मैंने Git सिर्फ़ 52 बार चलाया (जिनमें 11 बार --help था), जबकि Jujutsu 582 बार इस्तेमाल किया। किसी खास workflow के हिसाब से खुद को ढालने की ज़रूरत नहीं पड़ती; Jujutsu इतना flexible है कि लगभग हर workflow को support कर सकता है। चाहे आप इसे git की तरह ही इस्तेमाल करें, फिर भी commits और branches को आज़ादी से move कर सकते हैं (stash की ज़रूरत नहीं), आसानी से rebase कर सकते हैं (git experts के लिए यह परिचित होगा, लेकिन VSCode के git tools के बिना सीधे कर पाना बहुत राहत देता है), और VCS की झंझटों से बचे रहकर सिर्फ़ काम पर ध्यान दे सकते हैं। ध्यान देने वाली बात यह है कि history पहले की तरह git repo में भी बनी रहती है, इसलिए यह दूसरे git tools के साथ compatible है। यानी मेरे teammates को अपना VCS बदले बिना मैं कुछ और इस्तेमाल कर सकता हूँ। tags, submodules और LFS में थोड़ी कमी महसूस होती है, लेकिन फिर भी इसे आज़माना बनता है

    • जानना चाहूँगा कि git branch --set-upstream-to का jj में विकल्प क्या है

    • jjui इस्तेमाल करके देखें, फिर शायद ही कभी jj commands को हाथ लगाना पड़े। सच में कमाल है

  • Jujutsu वाकई काफ़ी अच्छा है। कुछ महीने पहले इसे इस्तेमाल किया था और इस पर कुछ पोस्ट भी लिखीं (यह वाली); तब से लगातार इसी का इस्तेमाल कर रहा हूँ। कुल मिलाकर यह बहुत “consistent” अनुभव देता है। सच कहूँ तो मैं git के साथ भी ठीक-ठाक सहज था, लेकिन jj में लगभग सब कुछ कुछ बुनियादी सिद्धांतों पर चलता है, और आप उन्हें अपनी ज़रूरत के हिसाब से जोड़कर complex history rewriting भी आसानी से कर सकते हैं। मैं पहले “stash-heavy” तरीके से काम करता था, लेकिन jj में automatic change tracking, changes को स्वतंत्र रूप से move करने की सुविधा आदि की वजह से यह git से काफ़ी ज़्यादा सहज लगता है। rebase और conflict resolution भी (ख़ासकर stash-style workflow में) बहुत बेहतर हैं। मैं इसे ज़ोरदार सिफ़ारिश करता हूँ, और switch करने की लागत भी बहुत कम है

  • निजी तौर पर, मुझे git के ऊपर एक नई layer जोड़ने वाला approach ज़्यादा पसंद नहीं है। समझता हूँ कि git की hegemony तोड़ना मुश्किल है, लेकिन अगर बिल्कुल नई foundation पर बनाया जाए, तो वह कहीं ज़्यादा powerful और मुक्त हो सकता है

  • मैंने लगभग एक महीने तक jj इस्तेमाल किया, फिर कंपनी के एक खास project की वजह से वापस git पर लौटना पड़ा। मुझे jj सच में बहुत पसंद आया, लेकिन बस उतना ही। फिर git पर लौटने के कुछ ही घंटों में मुझे jj की सुविधाएँ बहुत बुरी तरह याद आने लगीं: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

    • “बस उतना ही” से आपका ठीक-ठीक मतलब क्या है?

    • मतलब यह कि उसकी असली क़ीमत खोने के बाद समझ आती है

  • मैं “Jutustsu for Git experts” जैसे विषय पर और पढ़ना चाहूँगा। जैसे, क्या conflict को commit करना मेरे git rerere को ख़राब नहीं करेगा? या git में मुझे git add -p के साथ patch के सिर्फ़ कुछ हिस्सों को stage करके काम करना पसंद है—तो क्या jj में दो-स्तरीय patch set को आसान तरीके से संभालने का कोई तरीका है? मैं timestamps टूटने या बेवजह build system के फिर से rebuild होने जैसी समस्याओं से बचना चाहता हूँ

    • jj में सबसे आम workflow (“squash workflow”) के हिसाब से जवाब दूँगा। working directory यानी top commit में आज़ादी से changes करते रहें, और जब “stage” करना हो, तो नीचे वाले commit (यानी एक level नीचे) में squash down कर दें—चाहे सारे changes, या -i के साथ सिर्फ़ कुछ चुने हुए। और squash --into से किसी और commit को target करके जहाँ चाहें वहाँ squash कर सकते हैं

      1. jj में git rerere का इस्तेमाल नहीं होता, इसलिए यह सवाल थोड़ा ग़लत दिशा में है। 2. @ workspace है, और @- वह commit है जिस पर आप काम कर रहे हैं। jj squash -i से आप अपनी पसंद के diff हिस्सों को interactively वापस @ में ला सकते हैं

    • “stage/unstage का फ़र्क अनावश्यक है” इस बात से सहमत होने के बावजूद, “patch के मनचाहे हिस्से को stage करना सच में अच्छा है” यह राय दिलचस्प लगती है। git worktree, git diff, vi, git apply के संयोजन से बिना staging के मिलता-जुलता असर लिया जा सकता है, लेकिन यह वाकई बहुत झंझटभरा है। mercurial 7.1 में भी अब तक interactive add नहीं है, इसलिए worktree के ज़रिए workaround के अलावा कोई विकल्प नहीं है

  • हाल में Jujutsu के बारे में काफ़ी सुन रहा हूँ, लेकिन इसके ठोस workflows तक अभी नहीं पहुँचा। जानना चाहता हूँ कि Emacs Magit की तुलना में Jujutsu का कोई खास फ़ायदा है या नहीं। अब तक मैंने ज़्यादातर Git UI को कमज़ोर पाया है, लेकिन Magit की वजह से मेरी git productivity बहुत बढ़ी, और git का “जादू” भी महसूस हुआ। क्या Jujutsu इस अनुभव से प्रतिस्पर्धा करना चाहता है, या इसका लक्ष्य सिर्फ़ मौजूदा (और सच में कमज़ोर) git UI का विकल्प बनना है?

    • Jujutsu कोई साधारण git UI नहीं है; बल्कि git UI के रूप में यह अपेक्षाकृत कमज़ोर है (tags, submodules आदि का support कमज़ोर है)। यह एक बिल्कुल नया VCS है, जो backend में git का इस्तेमाल करता है। अगर git ने SVN की तुलना में “cheap branch” दिया था, तो JJ “cheap rebase” लाता है। conflicts पूरे काम को रोकते नहीं, rebase करना, commit structure को manage करना आदि बहुत आसान हो जाता है। अगर आपने stacked diffs इस्तेमाल किए हैं, तो यह परिचित लगेगा, और stacked diff PR बनाना jj में लगभग बिना मेहनत के हो जाता है

    • अगर आप पहले से Magit के भारी user हैं, तो jj के मूल concepts भी आकर्षक लगेंगे। jj ऐसी commit acrobatics संभव बनाता है जिन्हें पहले असंभव समझा जाता था (जैसे 5-way octopus merge की 2 leaves को conflict unresolved स्थिति में rebase करना)। यह “Mega Merge” नाम की तकनीक भी है, जो मैंने बनाई थी। Magit और jj में कुछ समानताएँ हैं, और मुझे लगता है कि “git का जादू” भी दरअसल tools की “design language” से आता है। Git तो बस Magit और jj दोनों के लिए physical storage layer है; algorithms, UX, concepts आदि में बहुत अंतर है। Magit users को jj कम झटका देता है, लेकिन advanced Git command-line users भी jj पर बहुत आसानी से आ जाते हैं और अक्सर इसके प्रबल समर्थक बन जाते हैं। वे commit graph manipulation में माहिर tools की ताकत को सबसे अच्छी तरह समझते हैं। संदर्भ के लिए, मैं jj maintainers में से एक हूँ, और मुझे यह बहुत अच्छी तरह बना हुआ tool लगता है। काश लोग कुछ दिनों के लिए Magit के बिना इसे आज़माएँ

    • यहाँ कुछ संबंधित links हैं। Megamerge workflow को अच्छी तरह समझाने वाले लेख: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, और jj cli को wrap करने वाला बेहतरीन TUI: https://github.com/idursun/jjui

    • मैं जानना चाहता हूँ कि Jujutsu का “मुख्य concept” क्या है। Git के industry standard होने की तुलना में Jujutsu अपनाने की कोई बहुत मज़बूत वजह मुझे साफ़ नहीं दिखती। concepts दिलचस्प लगते हैं, लेकिन अगर marketing के नज़रिए से थोड़ा और स्पष्ट संदेश हो, तो शायद अपनाने की संभावना बढ़े। Git की सबसे बड़ी कमज़ोरी यह है कि बाहरी लोगों के लिए यह बहुत unfriendly है (terminology, discoverability की कमी, GUI frontends की कमी आदि), इसलिए एक beginner-friendly VCS की संभावना बहुत बड़ी है

    • मैं Magit से jujutsu पर आ गया हूँ। सबसे बड़ा बदलाव यह है कि PR stack करना बहुत आसान हो गया, और मैंने changes को और छोटे हिस्सों में बाँटने की आदत विकसित कर ली है, जिससे “भेजने लायक” होने का मेरा मानदंड और सख्त हो गया है। कुल मिलाकर अनुभव सकारात्मक है, लेकिन अगर Magit आपके लिए पहले से बहुत अच्छा काम कर रहा है, तो कोई असाधारण बढ़त नहीं है। फिर भी https://github.com/bolivier/jj-mode.el की वजह से Emacs में jj आराम से इस्तेमाल किया जा सकता है

  • दिलचस्प लगा। ऑनलाइन काफ़ी सक्रिय रहने के बावजूद मैंने Jujutsu का नाम पहली बार अभी सुना है। Git को backend की तरह इस्तेमाल करके एक बेहतर VCS देने का विचार मुझे पसंद आया। इसका एक कारण यह भी है कि तब भी Github-Gitlab पर backup और sharing संभव रहती है। Fossil और Bitkeeper भी आकर्षक हैं, लेकिन वे git से इतने “काफ़ी बेहतर” नहीं बने कि git के network effects को हरा सकें। Jujutsu को थोड़ा चलाकर देखना चाहिए। पता नहीं लंबे समय तक इस्तेमाल करूँगा या नहीं, लेकिन उम्मीद है कि यह सोच से बेहतर निकलेगा