व्यस्त डेवलपर्स के लिए Jujutsu

(maddie.wtf)

2 पॉइंट द्वारा GN⁺ 2025-07-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Jujutsu(jj) Git की तुलना में अधिक सरल कॉन्सेप्ट और कमांड देने वाला, लेकिन शक्तिशाली version control system है
यह Git को backend के रूप में इस्तेमाल करता है, इसलिए इसे साथ-साथ इस्तेमाल करना या आसानी से Git पर वापस लौटना संभव है
stacked diff, आसान rebase, अस्थायी revision जैसी सुविधाएँ स्वाभाविक रूप से मिलती हैं
यह branch के बजाय bookmarks कॉन्सेप्ट का उपयोग करता है, जो वास्तविक कार्यप्रवाह में अधिक सहज है
conflict हैंडलिंग का तरीका लचीला है और रोज़मर्रा के version control कामों को काफी सरल बना देता है

Elevator Pitch

Jujutsu(jj) एक version control system है जो Git की तुलना में कहीं अधिक सरल mental model और command-line interface देता है।
बिना सुविधाओं की बलि दिए, वास्तव में इसे और भी अधिक शक्तिशाली कहा जा सकता है
stacked diff, आसान rebase, और अस्थायी revision जैसी सुविधाएँ स्वाभाविक रूप से काम करती हैं
क्योंकि यह backend में Git का उपयोग करता है, आप सिर्फ एक पंक्ति में Git repository के साथ-साथ इसका उपयोग शुरू कर सकते हैं और कभी भी Git पर लौट सकते हैं
इससे repository को संभालने के दूसरे उपयोगकर्ताओं के तरीके पर भी कोई असर नहीं पड़ता

Getting Started

jj command-line tool इंस्टॉल करने के बाद, user information और shell autocompletion सेट करने की सलाह दी जाती है
मौजूदा repository पर लागू करते समय, नई clone बनाना या बिना किसी बदलाव वाली स्थिति में शुरू करना बेहतर है
मौजूदा repository में jj git init --colocate . कमांड से Git और Jujutsu repository को साथ-साथ बनाया जा सकता है
jj repository data, Git की .git से अलग .jj/ फ़ोल्डर में रखा जाता है
Git और Jujutsu के बीच data synchronization सामान्यतः बिना समस्या के चलता है
लेकिन git clean -fdx कमांड .jj/ फ़ोल्डर को हटा देता है, इसलिए सावधानी ज़रूरी है
remote branch tracking भी उसी कमांड से एक बार में सेट किया जा सकता है

How To Use It

Jujutsu का command-line interface Git की तुलना में अधिक सीमित और संक्षिप्त है
मूल कॉन्सेप्ट सरल हैं, लेकिन workflow में थोड़ी आदत डालनी पड़ सकती है
सरल प्रक्रियाओं और उदाहरणों के साथ इसके मुख्य उपयोग समझाए गए हैं

Starting A New Revision

Git में नया काम आम तौर पर branch बनाकर शुरू होता है, लेकिन Jujutsu में नया revision बनाया जाता है
नवीनतम remote repository स्थिति लाने के लिए: jj git fetch
repository history देखने के लिए: jj log
history में revision, अलग-अलग Jujutsu revision ID और Git commit hash से पहचाने जाते हैं
नया काम शुरू करने के लिए jj new main से वर्तमान main के ऊपर नया revision बनाया जाता है
वर्तमान में edit हो रहा revision @ चिन्ह से पहचाना जाता है
जब समान prefix हट जाता है, तो revision ID का छोटा prefix भी उसी के अनुसार बदल जाता है

Making Changes

फ़ाइलों में बदलाव करते ही वे तुरंत उसी revision में शामिल हो जाते हैं (अलग staging area नहीं होता)
बदलाव पूरा होने पर jj describe -m "संदेश" से revision में message जोड़ें
नया revision बनाने के लिए jj new (या पिछला revision निर्दिष्ट करें)
jj commit, jj describe + jj new का संयुक्त operation है

Navigating

jj new से बना खाली revision, कहीं और जाने पर अपने-आप हटा दिया जाता है
किसी revision को स्पष्ट रूप से हटाने के लिए: jj abandon <rev ID>
हटाना वापस लेने के लिए: jj op undo
किसी मौजूदा revision पर वापस जाने के लिए jj edit <rev ID>
revision reference देते समय revset expressions भी इस्तेमाल किए जा सकते हैं:
- @: वर्तमान revision
- x-: parent revision
- y+: child revision
- z::: z के सभी descendant

Branches (Bookmarks)

Jujutsu में Git की तरह "किसी branch पर टिके रहने" की स्थिति नहीं होती
इसके बजाय bookmark सिर्फ एक pointer है जो किसी खास revision की ओर इशारा करता है
नया bookmark बनाने के लिए: jj bookmark create <नाम> -r <revision>
commit करने पर bookmark अपने-आप नहीं खिसकता, इसलिए ज़रूरत होने पर jj bookmark move <नाम> --to <revision> से अलग से ले जाना पड़ता है
push करते समय --allow-new फ़्लैग से remote पर नया branch बनाना स्वीकार किया जाता है
अगर bookmark remote से अलग हो, तो वह * से दिखता है और jj git push से sync किया जा सकता है

Conflicts

Jujutsu का conflict संभालने का तरीका Git की तुलना में अधिक लचीला है
conflict होने पर revision और उसके descendant revisions पर ‘conflicted’ निशान दिखता है
conflict वाली फ़ाइलों में conflict markers डाले जाते हैं, और उन्हें हटाकर समाधान किया जाता है
सीधे संपादन करके या नए revision में बदलाव के बाद jj squash से मिलाया जा सकता है

निष्कर्ष

अब तक Git में सबसे अधिक उपयोग होने वाले 80% कामों को Jujutsu से और सरल तरीके से करने का परिचय दिया गया
आगे चलकर सामान्य और उन्नत उपयोग के लिए इसे reference handbook (Quick Reference) के रूप में उपलब्ध कराया जाएगा
Git की तरह jj status कमांड भी समर्थित है
प्रश्न या फ़ीडबैक के लिए मुख्य लेख में दिए गए ईमेल का उपयोग किया जा सकता है

1 टिप्पणियां

GN⁺ 2025-07-23

Hacker News की राय

जो लोग सोच रहे हैं कि jj सीखना ठीक रहेगा या नहीं, उनके लिए मैं एक बात ज़रूर कहना चाहूँगा
Hacker News पर jj की बात करो तो लोग आम तौर पर दो तरह के मिलते हैं: जिन्होंने अभी तक इसे आज़माया नहीं है, और जो इसे बहुत ज़ोर से recommend करते हैं
मैंने लगभग कभी नहीं देखा कि कोई एक हफ्ते तक jj इस्तेमाल करके फिर git पर लौट गया हो
जिन लोगों ने इसे सच में गंभीरता से इस्तेमाल किया, वे लगभग सभी jj पर टिक गए
उम्मीद है आज ही वह दिन हो जब आप jj को आज़माएँ
जितना लगता है उससे कहीं आसान transition है; मैं उसी दिन productive था, और एक हफ्ते के भीतर मुझे git commands पर लौटने की बिल्कुल ज़रूरत नहीं पड़ी
मैं बहुत कम समय में ज़्यादा productive हो गया, और अब हैरानी होती है कि पहले मैं git कैसे इस्तेमाल करता था
- मुझे git productivity के हिसाब से बिल्कुल भी परेशान नहीं करता
  मैं हर दिन लंबे समय तक git commands इस्तेमाल नहीं करता, और ज़्यादातर मामलों में इससे काम में कोई दिक्कत नहीं होती
  अगर आपको repo को git से बहुत ज़्यादा manipulate करना पड़ता है, तो jj बेहतर हो सकता है, लेकिन मेरी स्थिति ऐसी नहीं है
  यह कुछ वैसा है जैसे कोई आपसे कहे कि vim जैसा ही लेकिन कुछ extra features वाला bim ज़रूर इस्तेमाल करो
  लेकिन मुझे कुछ बार और i दबाने की परवाह नहीं है, और न ही julia autocomplete की ज़रूरत है
  जिन लोगों के लिए jj बेहतर है, वे आनंद लें
- VCS UI के तौर पर jj निश्चित रूप से प्रगति है, लेकिन git power users के लिए इसकी कुछ सीमाएँ हैं
  gitattributes support न होने की वजह से अगर आपको git-crypt, git-lfs जैसे filters चाहिए हों तो असुविधा होगी
  line ending handling जैसी चीज़ों के कारण Windows पर compatibility भी कमज़ोर हो सकती है
  और git-annex, git-bug जैसे external tools भी oplog के साथ integrate नहीं होते, और history को बिखरा हुआ बना सकते हैं
- मैंने सचमुच एक हफ्ते से ज़्यादा इस्तेमाल करके फिर git पर वापसी की है
  मुझे व्यक्तिगत रूप से staging area वाला workflow ज़्यादा पसंद है; ज़्यादातर लोग git staging से नफरत करते हैं, लेकिन मेरे लिए यह ऐसा लाभ नहीं था कि मैं उसे jj में छोड़ दूँ
  आदतें बदली जा सकती हैं, लेकिन अभी मैं jj से बंधा हुआ नहीं हूँ
  भविष्य में इसे फिर से आज़माने के लिए तैयार हूँ
- मैंने कुछ महीनों तक jj इस्तेमाल किया और फिर performance issues की वजह से git पर लौट गया
  jj operations में कई सेकंड लगते थे, जबकि git project के आकार से परे तुरंत response देता था
  इसके अलावा jj इस्तेमाल करते समय मुझे थोड़ा ज़्यादा मानसिक बोझ महसूस होता था, और git पर लौटने के बाद सब कुछ हल्का लगा
  हो सकता है यह सिर्फ मेरे लंबे git अनुभव की वजह से हो
- “आख़िरकार लोग बस दो ही तरह के होते हैं” जैसा कहना अपने-आप में jj प्रचारकों की एक stereotypical line लगती है
jj की जो बात मुझे पागल कर देती है, वह यह है कि changes हमेशा अपने-आप staged हो जाते हैं
पुराने समय में SVN का ढाँचा ऐसा था, और मुझे लगा कि git ने explicit staging लाकर इसमें बहुत सुधार किया
repo में हमेशा commit से ज़्यादा changes पड़े रहते हैं, और अगली commit में सिर्फ वही चुनना जिन्हें आप शामिल करना चाहते हैं, यह git में सामान्य बात है
लेकिन jj (SVN सहित) में commit से पहले changes को अस्थायी रूप से बाहर निकालने जैसे झंझट वाले manual steps करने पड़ते हैं
- यह issue मेरे लिए भी दुविधा है
  staging हमेशा मुझे झंझट लगता था, इसलिए Mercurial इस्तेमाल करते समय भी मुश्किल होती थी
  जब 90% से ज़्यादा मामलों में auto add चाहिए होता है, तब यह उल्टा सुविधाजनक भी है, लेकिन समस्या उन files की है जिन्हें .gitignore में नहीं डाल सकते
  auto add बंद करो तो भी असुविधा है, चालू रखो तो भी कुछ खटकता है
  दोनों में से कोई भी पूरी तरह साफ़ समाधान नहीं है
- JJ का workflow थोड़ा अलग है; उदाहरण के लिए आप पहले base commit बनाते हैं, और उसके ऊपर anonymous commits stack करके काम करते हैं
  तैयार होने पर jj squash या jj split से उन्हें व्यवस्थित कर लेते हैं
- मैं jj commit -i, कई commands के -i option, और config में snapshot.auto-track="none()" इस्तेमाल करता हूँ
  Mercurial इस्तेमाल करते समय भी मैं कुछ ऐसा ही करता था
  असल में अगर आप absorb feature काफ़ी इस्तेमाल करते हैं, तो अनचाही files या chunks अपने-आप नज़रअंदाज़ हो जाते हैं
- क्या jj new command वही workflow नहीं देती जो आप चाहते हैं?
- jj tree में non-head branches को भी ठीक से track करता है, इसलिए rebase और merge बिना stash की ज़रूरत के smoothly काम करते हैं
auto-added changes की आदत डालना आसान नहीं है
कभी-कभी local में कोई खास file सिर्फ development के दौरान थोड़ी देर के लिए बदलनी होती है, commit करने का इरादा नहीं होता
git में जब तक उसे stage न करो, वह कभी commit/push नहीं होगी, इसलिए भरोसा रहता है
लेकिन jj में लगता है जैसे कुछ unstage करना पड़ेगा या ज़्यादा सावधान रहना होगा
यह शायद आदत का मामला हो, लेकिन मैं स्पष्ट रूप से वही चुनना पसंद करता हूँ जिसे मैं commit करना चाहता हूँ
सोच रहा हूँ कि कहीं मैंने jj को गलत समझ तो नहीं लिया
- jj में आप jj split से changes अलग कर सकते हैं
  जो आप चुनते हैं वह पहली revision में चला जाता है, और बाकी दूसरी revision में व्यवस्थित हो जाता है
  जब आप कई काम एक साथ करते हैं और उन्हें छोटे-छोटे revisions में बाँटते हैं, तब यह git से कहीं आसान लगता है
  git की तरह नई revision (jj new) बनाकर changes करो, फिर jj squash -i से सिर्फ वही हिस्सा ले जाओ जो चाहिए
  conceptually, @ current revision है और @- एक कदम पहले वाली, इसलिए इसे git की working copy/stage जैसा समझ सकते हैं
- jj की auto staging हमेशा अच्छी चीज़ नहीं है
  अच्छा होता अगर jj docs और beginners, दोनों यह और साफ़ बताते कि default behavior को आसानी से बंद किया जा सकता है
  ~/.jjconfig में
  [snapshot]
  auto-track = "none()"
  ऐसे लिख दें
- मैं आम तौर पर काम के बाद jj split से review करके commit करने लायक हिस्से अलग करता हूँ
  यह workflow git के add -p जैसा ही महसूस होता है
  ऊपर वाला commit अक्सर उस working copy की तरह इस्तेमाल किया जा सकता है जिसे push नहीं करना है
  branch बदलते समय भी बिना stash के in-progress changes सुरक्षित रहते हैं
- हाँ, वह आदत मेरे लिए भी आसानी से नहीं बदली
  इसे बदलने के पक्ष में तर्क यह है कि code को untracked state में चलाना नहीं चाहिए
  अर्थपूर्ण changes को commits में रखना और बाकी को record न करना ज़्यादा सुरक्षित है
  समस्या तब आती है जब पूरे repo की settings और local settings अलग नहीं रखी जा सकतीं; VSCode इसका प्रमुख उदाहरण है
  ऐसे मामलों में environment-specific ऐसे changes चाहिए होते हैं जिन्हें commit नहीं करना चाहिए, और चीज़ें और जटिल हो जाती हैं
- अगर आपको ऐसा workflow चाहिए, तो jj में @ को git index की तरह मान सकते हैं, और commit के समय @- में squash करके git add --patch जैसा प्रभाव पा सकते हैं
मैं टीम को jj पर लाने की कोशिश कर रहा हूँ, लेकिन अभी सफल नहीं हो पाया
अच्छा होता अगर कोई ऐसा पेज होता जो एक नज़र में दिखा दे कि git के जटिल काम jj में कितने आसान हो जाते हैं
कुछ elevator pitch जैसा, बहुत संक्षेप में
अब लग रहा है कि मुझे खुद demo देकर दिखाना पड़ेगा
- मुझे नहीं लगता कि git में लोग जो आम काम करते हैं, वे jujutsu में अनिवार्य रूप से आसान हो जाते हैं
  बल्कि jujutsu में कुछ ऐसे नए workflows हैं जो git में या तो असंभव हैं या बहुत झंझट वाले
  जो developers पहले से git के आदी हैं, उनके लिए यह बात शायद तुरंत प्रभावशाली न लगे
- मैं खुद भी git का विशेष प्रशंसक नहीं हूँ
  पहले मैं सिर्फ mercurial इस्तेमाल करता था, लेकिन अब git मेरे दिमाग में बैठ चुका है
  भले ही Jujutsu में कुछ ठोस फायदे हों, लेकिन अभी उसमें उतना आकर्षण नहीं दिखता कि मैं initial setup तक की झंझट उठाऊँ, जैसे जटिल color settings या अपने परिचित scripts सेट करना
- jj और git के बीच एक प्रतिनिधि task comparison ने मेरी समझ में बहुत मदद की
  https://lottia.net/notes/0013-git-jujutsu-miniature.html
- कुछ अच्छे links भी सुझाता हूँ जो मददगार हो सकते हैं
  https://v5.chriskrycho.com/essays/jj-init/
  https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/
  https://ofcr.se/jujutsu-merge-workflow
- मुझे लगता है कि इस post में जो अगली चीज़ मैं जोड़ने वाला हूँ, वह आपको पसंद आएगी
  जल्द ही उसे पेज के नीचे और एक अलग post के रूप में डालूँगा
कुछ हफ्तों तक jj इस्तेमाल करने के बाद मैंने auto commit message script भी बनाई
आज मैं वही script एक पुराने git repo पर port करने की कोशिश कर रहा था, तभी एहसास हुआ कि git में commit/ammend के सही समय को अपने-आप पहचानने वाला code लिखना पड़ेगा
jj में immutable commit structure की वजह से script बहुत सरल थी
मैंने बस repo को jj से फिर से clone कर लिया
commit और amend के बीच के भ्रम से मैं तुरंत मुक्त हो गया
https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/scripts/jj-auto.fish
- दोबारा re-clone करने की भी ज़रूरत नहीं है; मौजूदा git repo में jj साथ-साथ इस्तेमाल कर सकते हैं
git काफ़ी अच्छी तरह काम करता है
थोड़ा learning curve है, लेकिन एक बार समझ में आ जाए तो सब समझ आता है
ईमानदारी से कहूँ तो 95% स्थितियों में सिर्फ pull, add, reset, branch, commit जानना ही काफी है
- मेरे workflow में stacked diff अनिवार्य है
  यह review के इंतज़ार में रुके बिना आगे के काम को भी stack करने देता है
  git में setup मुश्किल नहीं है, लेकिन stack के निचले हिस्से में changes जोड़ना और फिर सब कुछ restack करना सचमुच नर्क है
- collaboration वाले मामलों में rebase/squash की समझ ज़रूरी है
  जब तक आप पूरी टीम को यह न मनवा लें कि वे इन्हें न इस्तेमाल करें, तब तक इससे बचा नहीं जा सकता
  खासकर जब कई लोग एक branch पर जल्दी-जल्दी development कर रहे हों, तब git की आदतें असुविधाजनक लगने लगती हैं
  मूल रूप से यह सुविधाजनक है, लेकिन जटिल परिस्थितियों में समस्याएँ बहुत हैं
- बस थोड़ा-सा uncommon scenario भी देख लो, git की कमियाँ दिखने लगती हैं
jj इस्तेमाल किए मुझे लगभग 2 हफ्ते हुए हैं, और पहली बार मैं सिर्फ command line से version control आराम से चला पा रहा हूँ
git इस्तेमाल करते समय मैं हमेशा GUI (Git Graph in VSCode) में right-click ज़्यादा करता था
लेकिन jj में सिर्फ tutorial पढ़कर भी मैं तुरंत एक consistent command-line workflow में आ गया
हाँ, jj log में IDs बार-बार copy-paste करने से बचना है तो शायद revset language सीखनी पड़ेगी
- मेरी भी स्थिति कुछ ऐसी ही है
  मैंने git लंबे समय तक इस्तेमाल किया, लेकिन जटिल चीज़ें हमेशा UI से ही संभालीं
  लगभग एक महीने से सिर्फ jj CLI इस्तेमाल कर रहा हूँ और काफ़ी संतुष्ट हूँ
  लेकिन jj की official docs इस मानकर लिखी गई लगती हैं कि आपको पहले से basic knowledge है, इसलिए beginners के लिए कभी-कभी उलझन होती है
  उम्मीद है कि और blogs और tutorials आएँगे
  मैं भी revset language और rebase को थोड़ा और सीखना चाहता हूँ
  सरल CLI, conflict resolution, और oplog—तीनों मुझे पसंद हैं
- मुझे भी ID copy-paste करना असुविधाजनक लगता था, लेकिन jjui(https://github.com/idursun/jjui) इस्तेमाल करने के बाद सब बहुत smooth हो गया
  अब मैं लगभग log को skim करते हुए तेज़ी से काम कर लेता हूँ
मेरे हिसाब से jj की सबसे बेहतरीन feature undo है
git में undo करना गलती के प्रकार के हिसाब से अलग-अलग command माँगता है, इसलिए कठिन लगता है
jj में बस एक बार jj undo काफ़ी है
यह backend system से बँधा भी नहीं है, इसलिए आप local में अकेले jj इस्तेमाल करें तो teammates पर कोई असर नहीं पड़ता
मुझे समझ नहीं आ रहा कि jj आखिर है क्या
क्या यह उन लोगों के लिए frontend है जिन्हें git confusing लगता है?
कहा जाता है कि यह backend abstraction देता है, लेकिन git का असर इसमें इतना ज़्यादा दिखता है कि Perforce, Piper जैसे उन systems में इसकी कल्पना करना मुश्किल है जहाँ sequential numbered commits लागू होते हैं
working copy = commit वाली design मुझे quality control के खिलाफ लगती है
commit का मूल मतलब यही है कि सिर्फ वही चीज़ें ऊपर जाएँ जो जानबूझकर चुनी गई हों, लेकिन ऐसी संरचना में “garbage commits” को अलग करना और मुश्किल हो जाता है
git और jj दोनों ही बड़े projects के सामने कमज़ोर लगते हैं, और commit फैलाव को रोक न पाना भी जैसे बना हुआ है
मैं समझना चाहता हूँ कि jj वास्तव में कौन-सी समस्या हल करता है; कहीं यह सिर्फ author की पसंद का frontend तो नहीं
- Piper backend तो वास्तव में Git backend से भी ज़्यादा natural लगता है
  jj commits, git commits से one-to-one पूरी तरह मेल नहीं खाते, इसलिए इसे लेकर गलतफहमी की ज़रूरत नहीं है
  असल में “commit” को “named diff” की तरह समझना बेहतर है, और push से पहले changes को कभी भी आसानी से दोबारा गढ़कर व्यवस्थित किया जा सकता है
  यह git में rebase या history editing से कहीं आसान है
  मैं बीच काम में experiment, docs वगैरह के कई commits बना लेता हूँ, जिन्हें git में शायद stash या किसी temporary branch में ठूँसना पड़ता
- jj सिर्फ git frontend से बढ़कर है
  यह एक version control system है, और backend-agnostic है
  इसका सबसे प्रमुख backend git है, इसलिए मौजूदा repo में तुरंत switch किया जा सकता है
  मैं github आने से पहले से git इस्तेमाल कर रहा हूँ, लेकिन jj इस्तेमाल करने के बाद अब git पर लौटना मुश्किल लगता है
  jj ज़्यादा simple भी है और powerful भी
  working copy = commit को वास्तव में “index भी एक commit है” की तरह समझना चाहिए
  उदाहरण के लिए अगर feature x पर काम शुरू करना है, तो jj new -m "working on feature x" trunk से नया commit बनाओ, और उसके ऊपर एक खाली commit और रख दो
  आपका काम working copy (@) में जाता है, फिर उसे पिछले commit (@-) में “ले जाकर” (squash) git के add-p, reset जैसी जटिल options की जगह commits के बीच diff से सब संभाला जाता है
  इसी संरचना की वजह से commits को बाँटना और व्यवस्थित करना git index की तुलना में ज़्यादा flexible और powerful हो जाता है
  commit बिखराव की समस्या ज़्यादा करीब से pull request culture से जुड़ी है, और jj भी इसे सिर्फ कुछ हद तक ही हल कर सकता है
- working copy को ऐसे ही GitHub पर push नहीं कर दिया जाता; commit description जोड़ते समय review/cleanup किया जा सकता है
मैंने jj कुछ दिन इस्तेमाल किया, लेकिन अपने मौजूदा lazygit, workflow, और script setup से मैं काफ़ी संतुष्ट हूँ
jj नया और ठीक-ठाक लगता है, लेकिन अगर आप अभी-अभी version control शुरू नहीं कर रहे हैं, तो switch करने की ठोस वजह कम लगती है
- GitButler जैसे दूसरे tools इस्तेमाल करें तो frontend का महत्व कम हो जाता है, लेकिन मैंने कुछ दिन पहले Jujutsu अपनाया और Claude से उसके मुख्य operations (commit, branch move, GitHub push/pull) पूछे, और 10 मिनट में हाथ साफ़ हो गया
  मैं अभी भी Lazygit का diff इस्तेमाल करता हूँ, लेकिन detached HEAD state में रहने पर भी कोई समस्या नहीं होती
  JJ का git के साथ अच्छा compatibility है, और जटिल commands याद किए बिना बहुत आसान तरीके से सब कुछ करा देता है
  branches के बीच जाते समय uncommitted files का अपने-आप साथ चलना इसकी सबसे बेहतरीन features में से है
  development, bug fix, copy changes जैसी अलग-अलग चीज़ों के बीच आना-जाना बहुत आसान हो जाता है
  अगर AI agent changes कर रहा हो, तो worktree अलग करके इस्तेमाल किया जा सकता है
  काम पूरा होने से पहले ही change description (= commit message) लगाकर उसे tree में पहले से देख पाना भी सच में बहुत अच्छा है
  कुल मिलाकर JJ काफ़ी शानदार है