jj – Jujutsu के लिए CLI

 (steveklabnik.github.io)
2 पॉइंट द्वारा GN⁺ 2026-04-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • jj, Jujutsu का command-line interface है, जो distributed version control system (DVCS) आधारित टूल है
  • यह git से अधिक सरल और सहज होने के साथ-साथ अधिक शक्तिशाली features प्रदान करता है
  • git और Mercurial के फ़ायदों को जोड़कर core tools की संख्या घटाता है और organic integration को मज़बूत करता है
  • git-compatible backend का उपयोग करके मौजूदा collaboration environment को बनाए रखते हुए भी स्वतंत्र experimentation संभव बनाता है
  • advanced users के लिए git में कठिन अतिरिक्त version control features का उपयोग कर पाना महत्वपूर्ण है

jj का परिचय और विशेषताएँ

  • jj Jujutsu का CLI (command-line interface) है, और Jujutsu एक distributed version control system (DVCS) है

    • उपयोगकर्ता git जैसे अन्य DVCS से परिचित हो सकते हैं, और यह tutorial git users के दृष्टिकोण को आधार मानता है
    • jj को git से अधिक सरल, उपयोग में आसान, और फिर भी शक्तिशाली टूल के रूप में डिज़ाइन किया गया है
    • आम तौर पर “शक्तिशाली” और “जटिल” एक-दूसरे के विपरीत माने जाते हैं, लेकिन jj इस संतुलन को नए तरीके से प्रस्तुत करता है
    • jj git और Mercurial(hg) की खूबियों को मिलाकर DVCS का एक नया रूप बनाता है
    • यह core tools की संख्या घटाकर और हर टूल के बीच organic integration के ज़रिए अधिक कुशल कार्य-परिवेश देता है
    • advanced users, git में कठिन अतिरिक्त version control features का उपयोग कर सकते हैं
    • jj git-compatible backend का उपयोग करता है, इसलिए collaboration environment बदले बिना स्वतंत्र experimentation संभव है
    • यह मौजूदा git repositories के साथ compatibility बनाए रखता है, और आवश्यकता होने पर आसानी से git पर वापस लौटा जा सकता है
    • tutorial इन विशेषताओं के माध्यम से सीधे दिखाने का संकेत देता है कि jj क्यों ध्यान देने योग्य टूल है

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

1 टिप्पणियां

 
GN⁺ 2026-04-15
Hacker News टिप्पणियाँ

  • बहुत-सी चर्चा git और jj के अंतर पर केंद्रित है, लेकिन मेरा मानना है कि बस git को भूलकर jj के मूल workflow पर ध्यान देना बेहतर है
    एक साफ repository में jj चलाने पर स्थिति देख सकते हैं, और बदलाव के बाद jj commit -m "made changes" से commit कर सकते हैं
    गलती हो जाए तो सुधार करके jj squash से उसे आख़िरी commit में मिला सकते हैं
    जब किसी खास revision से, जैसे नई branch की तरह, काम करना हो तभी jj new -r lmnop इस्तेमाल करें
    git history को git log से देखा जा सकता है, और jj का आंतरिक कामकाज दिखाई नहीं देता

    • मैं भी कुछ ऐसा ही चाहता था, इसलिए alias.save="!git add -A; git commit -m" जैसा git alias बनाकर $ git save "made changes" की तरह इस्तेमाल करता था

  • JJ मुझे उल्टा सोचने के लिए कहता हुआ लगता है
    git में बदलाव के बाद commit message लिखा जाता है, लेकिन jj में पहले नया commit बनता है और फिर उसमें विवरण जोड़ा जाता है
    कई features मिले-जुले गंदे state में से सिर्फ ज़रूरी बदलाव चुनकर commit करने की आदत है, लेकिन सिर्फ jj tutorial देखकर यक़ीन नहीं होता कि यह संभव है या नहीं

    • jj new एक खाली git staging area जैसी अवधारणा है
      jj में हमेशा commit मौजूद रहता है, और वह commit folder की contents के आधार पर निकाले गए मान के रूप में stable changeid रखता है
      अगर कई बदलावों को अलग-अलग commit करना हो तो jj split का इस्तेमाल किया जा सकता है
    • मैं अक्सर jj new से अस्थायी commit बनाता हूँ और message खाली छोड़ देता हूँ
      बाद में तैयार होने पर कई commits को squash करके एक में मिला देता हूँ और message जोड़ता हूँ
      यह तरीका एक तरह की undo history की तरह काम करता है, इसलिए प्रयोग करना बहुत आसान हो जाता है
    • असल में jj new सिर्फ “ऊपर एक नया commit बनाना” है, इसलिए तुरंत विवरण लिखने की ज़रूरत नहीं होती
      मैंने भी शुरू में यह आदत डालने की कोशिश की थी, लेकिन उल्टा यह गैर-प्रभावी लगा
    • JJ में यह तरीका मानक है
      Git में भी इसी तरह का workflow सुझाया गया है, और Squash Workflow देखने पर Git index जैसा flow बनाया जा सकता है
    • मेरे साथ भी अक्सर ऐसा होता है कि कई बदलाव करते-करते अलग-अलग features आपस में मिल जाते हैं
      इसलिए मैं कई workspaces रखता हूँ और shelve feature (IntelliJ) का अक्सर उपयोग करता हूँ
      कभी-कभी git patch से diff को अस्थायी रूप से भी सहेजता हूँ
      इस तरह की अव्यवस्थित प्रक्रिया को साथियों से छिपाकर थोड़ा और professional दिखने की कोशिश करता हूँ

  • jj इस्तेमाल करके जो बात मुझे पसंद नहीं आई, वह यह है कि file edit अपने-आप commit हो जाती है
    अगर पुरानी commit को देखने के लिए checkout करने के बाद file बदल दें, तो वही commit बदल जाती है और उसके बाद की पूरी history rebase हो जाती है
    इसलिए बचाव के तौर पर एक खाली commit पहले बनानी पड़ती है
    git में जब तक मैं साफ़ तौर पर commit नहीं करता, repository नहीं बदलती, इसलिए वह ज़्यादा सहज लगता है

    • मैं भी पहले ऐसा ही सोचता था, लेकिन jj evolog जानने के बाद राय बदल गई
      jj के पास staging से बेहतर समाधान पहले से था
      git CLI की आदत ही jj सीखने में रुकावट बन रही थी
      दिलचस्प बात यह है कि jj इस्तेमाल करने पर git के storage engine structure को और बेहतर समझा जा सकता है
    • edit की जगह jj new का इस्तेमाल करें, तो बदलावों को साफ़-सुथरे ढंग से ट्रैक किया जा सकता है
      यह git stash को juggling करने से कहीं बेहतर लगता है
    • jj edit jj का सबसे बड़ा जाल है
      इसकी जगह jj new का इस्तेमाल करें, और गलती होने पर jj undo से वापस लौट सकते हैं
      jj commit को सस्ते snapshot की तरह मानता है, इसलिए commit से ज़्यादा “बदलाव” पर ध्यान देना सही है
      auto rebase push के बाद immutable होकर सुरक्षित रहता है
    • file edit का अपने-आप commit होना jj की मुख्य विशेषता है
      jj new और jj squash को मिलाकर इसे git branch head की तरह संभाला जा सकता है
      detached head state में काम करना jj बहुत आसान बना देता है
    • शायद आपने jj edit से पुरानी commit checkout की थी
      jj new पर स्विच करने से समस्या हल हो जाएगी

  • jj का आख़िरी paragraph ही मुख्य बिंदु है
    क्योंकि यह git के साथ पूरी तरह संगत backend इस्तेमाल करता है, इसलिए पूरी टीम को बदले बिना आप अकेले इसे आज़मा सकते हैं
    पसंद न आए तो कभी भी git पर वापस जा सकते हैं

    • लेकिन LFS, submodule, या hook इस्तेमाल करने वाले संगठनों में अपवाद हो सकते हैं
    • यह पूरी तरह compatible नहीं है। Interop संभव है, लेकिन पूरी तरह seamless नहीं
      git के operations jj log में दर्ज नहीं होते, इसलिए उन्हें manually import करना पड़ता है
      किसी project में एक ही interface इस्तेमाल करने की सलाह दी जाती है
    • पहले मैं भी git को CVS, Subversion के साथ इसी तरह इस्तेमाल करता था
    • लेकिन git और jj को एक ही directory में एक साथ इस्तेमाल करने पर चीज़ें टूट सकती हैं

  • मेरा सबसे पसंदीदा feature jj absorb है
    यह current revision के बदलावों को अपने-आप पहले की संबंधित commits में ले जाता है
    config file या .gitignore में बदलाव करना भूल जाने पर यह बहुत काम आता है
    jj new के बाद बदलाव करें और फिर jj absorb चलाएँ
    और सबसे अच्छी बात यह है कि merge conflict से जूझना नहीं पड़ता

    • अगर jj absorb ग़लत जगह लागू हो जाए, तो jj undo से वापस लौटा जा सकता है
      इसी feature की वजह से जटिल rebase भी डरावना नहीं लगता
    • जानकारी के लिए, git में भी git absorb मौजूद है

  • मैं लंबे समय से tutorial update नहीं कर पाया हूँ, लेकिन अब भी हर दिन jj इस्तेमाल करता हूँ
    startup ersc.io में व्यस्त होने की वजह से upstream पर काम नहीं कर पाया
    कोई भी सवाल हो तो हमेशा स्वागत है

    • git और jj के बीच DAG immutability का अंतर ही मुख्य बात है
      jj stable change ID इस्तेमाल करता है, जबकि git immutable commit ID इस्तेमाल करता है
      इसलिए jj में undo या rebase काफ़ी ज़्यादा लचीला लगता है
    • jj “ग़ैर-रोचक” बदलावों को अपने-आप छिपा देता है
      कभी-कभी ज़्यादा बदलाव एक साथ देखने का मन होता है; जानना चाहता हूँ कि क्या इसके लिए कोई विकल्प है

  • jj, git से अलग है, इसलिए इसे आज़माना सार्थक है
    सिर्फ़ अलग approach का अनुभव करने से ही engineering नज़रिया व्यापक होता है
    हर चीज़ आज़माना ज़रूरी नहीं, लेकिन अलग-अलग workflows के trade-offs समझना महत्वपूर्ण है

    • बेशक, 99% मामलों में बहुत कम फ़ायदे वाली कोशिश समय की बर्बादी भी हो सकती है

  • git और jj का रिश्ता C और Python जैसा लगता है
    git forensic tracking है, और jj कहानी के chapters जैसा है
    कभी-कभी बाद की कहानी को स्वाभाविक बनाने के लिए शुरुआती chapters फिर से लिखने पड़ते हैं

    • jj जो करता है, वह git में भी संभव है, लेकिन git की आदतन सोच बीच में बाधा बनती है
      jj को इस दर्शन के साथ बनाया गया है कि “working tree ख़ुद commit है” और “conflict भी commit किए जा सकते हैं”

  • “ज़्यादा ताकतवर और आसान” होने के दावे के लिए ठोस उदाहरण चाहिए लगते हैं

    • jj के कुछ फ़ायदों की बात करें तो:
      • rebase/merge conflict को तुरंत हल करना ज़रूरी नहीं
      • commit manipulation बहुत आसान है, खासकर jjui इस्तेमाल करने पर
      • jj के पास git की state changes को ट्रैक करने वाला operation log है
      • unnamed branches की वजह से experimental काम खुलकर किया जा सकता है
      • git के साथ पूरी compatibility होने से टीम में mixed use संभव है
    • जब हम SVN से git पर आए थे, तब बड़ा सुधार महसूस हुआ था, लेकिन अभी के git workflow में कोई बड़ी असुविधा नहीं है
    • एक ही repository में कई PRs पर साथ-साथ काम करके, हर एक को उसके हिसाब से push किया जा सकता है
      अगर ऐसी ज़रूरत नहीं है, तो शायद jj की अहमियत महसूस न हो
    • jj की असली आकर्षण commands में नहीं, बल्कि intuitive workflow में है
      इसे समझने के लिए ख़ुद इस्तेमाल करना पड़ता है
    • सिर्फ़ jj undo ही अपने-आप में काफ़ी मूल्यवान है
      git में आसानी से ऐसी स्थिति आ जाती है जहाँ recovery मुश्किल होती है, लेकिन jj में कुछ undo से बात संभल जाती है

  • jj की वजह से non-linear DAG का उपयोग करने में आत्मविश्वास आया है
    कई parents या children वाले बदलावों को अब स्वतंत्र रूप से संभालता हूँ
    पहले मैं बेवजह क्रम थोपता था, लेकिन अब dependency relation को साफ़ तौर पर व्यक्त कर सकता हूँ
    review और submit प्रक्रिया भी काफ़ी अधिक प्रभावी हो गई है

    • जानना चाहता हूँ कि क्या आप ऐसे branch किए गए बदलावों के ऊपर mega-merge + absorb workflow इस्तेमाल करते हैं