Git worktree मौजूदा Git रिपॉजिटरी से जुड़ी एक अतिरिक्त कार्य डायरेक्टरी है। इसकी अपनी चेक-आउट शाखा, अपना अलग इंडेक्स और अपनी अनट्रैक्ड फाइलें होती हैं, लेकिन यह मुख्य प्रोजेक्ट के साथ Git ऑब्जेक्ट स्टोर, रेफ़रेंसेज (refs) और कॉन्फ़िगरेशन को पूरी तरह साझा करती है। समानांतर AI कोडिंग एजेंटों के लिए यह सबसे सटीक अलगाव इकाई (isolation unit) है: प्रत्येक एजेंट को एक ऐसी डायरेक्टरी मिलती है जिसमें कोई अन्य प्रोसेस नहीं लिखता; उसके कमिट एक ऐसी शाखा पर दर्ज होते हैं जिसे किसी अन्य ने चेक-आउट नहीं किया है; और उस डायरेक्टरी को बनाना धीमे रिपॉजिटरी क्लोन या भारी कंटेनर स्टार्ट के बजाय एक त्वरित चेक-आउट ऑपरेशन मात्र है। यह लेख बुनियादी कमांड्स, वर्क-ट्री के साझा डायरेक्टरी से बेहतर होने के कारण, व्यावहारिक चुनौतियों और Ivy Tendril द्वारा प्रत्येक योजना के लिए वर्क-ट्री बनाने तथा मर्ज के बाद उसे हटाने की प्रक्रिया की व्याख्या करता है।
Git Worktree क्या है
डिफ़ॉल्ट रूप से प्रत्येक Git रिपॉजिटरी में केवल एक कार्य डायरेक्टरी होती है। git worktree add कमांड आपको अतिरिक्त डायरेक्टरीज़ जोड़ने की सुविधा देती है। प्रत्येक अतिरिक्त फोल्डर एक संपूर्ण चेक-आउट परिवेश होता है जहां आप cd कर सकते हैं, फाइलें बदल सकते हैं, बिल्ड चला सकते हैं और कमिट कर सकते हैं।
# एक डायरेक्टरी ऊपर एक नई शाखा पर वर्क-ट्री बनाएं
git worktree add ../feature-x -b feature-x
# इस रिपॉजिटरी के सभी वर्क-ट्री सूचीबद्ध करें
git worktree list
# /Users/dev/app a1b2c3d [main]
# /Users/dev/feature-x a1b2c3d [feature-x]
नई बनी डायरेक्टरी में एक .git फाइल होती है, न कि .git फोल्डर। यह फाइल मुख्य रिपॉजिटरी के .git/worktrees/feature-x की ओर इंगित करती है, जो उस विशेष वर्क-ट्री के इंडेक्स और HEAD को संभालती है। ऑब्जेक्ट्स, रेफ़रेंसेज, Git हुक्स और कॉन्फ़िगरेशन मुख्य रिपॉजिटरी से पढ़े जाते हैं। ../feature-x में किया गया कोई भी कमिट तुरंत मुख्य डायरेक्टरी से git log feature-x द्वारा देखा जा सकता है — बिना किसी पुश या फेच के।
इस डिज़ाइन से दो महत्वपूर्ण नियम सामने आते हैं: एक शाखा को एक समय में केवल एक ही वर्क-ट्री में चेक-आउट किया जा सकता है; और वर्क-ट्री डायरेक्टरी को मुख्य कार्य फोल्डर के बाहर स्थित होना चाहिए ताकि वह अनट्रैक्ड फाइलों के रूप में भ्रमित न हो।
एजेंटों के लिए वर्क-ट्री साझा डायरेक्टरी से बेहतर क्यों है
एक कोडिंग एजेंट फाइलें पढ़ता और संपादित करता है, कमांड चलाता है और कमिट करता है। यदि दो एजेंट एक ही डायरेक्टरी में ऐसा करते हैं, तो उनका diff आपस में उलझ जाता है, और परीक्षण किसी एक एजेंट के काम को अलग से सत्यापित नहीं कर पाते। इसके विकल्प प्रति एजेंट पूर्ण क्लोन, प्रति एजेंट डॉकर कंटेनर या प्रति एजेंट Git वर्क-ट्री हैं।
| दृष्टिकोण | स्वतंत्र ट्री और शाखा | साझा ऑब्जेक्ट स्टोर | स्टार्टअप लागत | रनटाइम अलगाव |
|---|---|---|---|---|
| साझा डायरेक्टरी | नहीं | हाँ | शून्य | कोई नहीं |
| प्रति एजेंट पूर्ण क्लोन | हाँ | नहीं (पूर्ण डेटा प्रतिलिपि) | धीमा क्लोन + पैकेज इंस्टॉल | कोई नहीं |
| प्रति एजेंट कंटेनर | हाँ | नहीं (जब तक माउंट न हो) | इमेज डाउनलोड + कंटेनर बूट | पूर्ण |
| प्रति एजेंट वर्क-ट्री | हाँ | हाँ | तत्काल चेक-आउट | कोई नहीं |
वर्क-ट्री एजेंट को कार्यात्मक सटीकता के लिए आवश्यक सब कुछ (एक निजी फाइल ट्री और एक निजी शाखा) प्रदान करता है, बिना किसी अनावश्यक वर्चुअलाइजेशन ओवरहेड के। चूंकि ऑब्जेक्ट स्टोर साझा होता है, इसलिए वर्षों के इतिहास वाले बड़े प्रोजेक्ट में भी केवल वर्तमान स्नैपशॉट के चेक-आउट की आवश्यकता होती है। pnpm, Cargo या NuGet जैसे पैकेज मैनेजर कैश उपयोगकर्ता की होम डायरेक्टरी में पहले से साझा होते हैं।
जब एजेंटों को ऑपरेटिंग सिस्टम पैकेज इंस्टॉल करने हों या नेटवर्क पोर्ट बाइंड करने हों, तो डॉकर कंटेनर ही सही विकल्प हैं। दोनों विधियाँ परस्पर विरोधी नहीं हैं: एक वर्क-ट्री को कंटेनर में आसानी से माउंट किया जा सकता है। सामान्य कोडिंग, परीक्षण और लिंटिंग के लिए केवल वर्क-ट्री पर्याप्त से अधिक है।
अधिक जानकारी के लिए एजेंट ऑर्केस्ट्रेशन पैटर्न पढ़ें।
संभावित विफलताएं और उनसे कैसे बचें
वर्क-ट्री फाइलों के टकराव को हल करते हैं, लेकिन उन्हें तीन अन्य समस्याओं से निपटने के लिए नियमों की आवश्यकता होती है।
1. दो एजेंट अलग-अलग शाखाओं पर एक ही फाइल को संपादित करते हैं
वर्क-ट्री डायरेक्टरी को अलग करते हैं, इंजीनियरिंग के इरादे को नहीं। यदि दो योजनाएं एक साथ auth/session.ts में बदलाव करती हैं, तो दोनों शाखाएं स्वतंत्र रूप से कमिट हो जाएंगी, लेकिन बाद में मर्ज होने वाली शाखा में कॉन्फ्लिक्ट आएगा। इसे योजना बनाते समय ही पकड़ना चाहिए: प्रभावित मॉड्यूल की पहचान करें और योजनाओं को क्रमबद्ध करें या कार्यों को इस प्रकार विभाजित करें कि प्रत्येक मॉड्यूल का एक ही मालिक हो।
2. अनकमिटेड बदलाव (Dirty Trees)
यदि कोई एजेंट असामान्य रूप से रुक जाता है या परीक्षण अस्थायी फाइलें उत्पन्न करते हैं, तो वर्क-ट्री में अनकमिटेड फाइलें रह जाती हैं। git worktree remove सुरक्षा कारणों से ऐसे फोल्डर को हटाने से मना कर देता है। एक मजबूत ऑर्केस्ट्रेटर की नीति यह होती है कि वह एजेंट द्वारा बनाई गई सभी फाइलों को उसकी शाखा पर कमिट कर दे ताकि कुछ भी खोए नहीं, और केवल उसके बाद ही वर्क-ट्री को सुरक्षित रूप से हटाए।
# हटाने से पहले स्थिति जांचें
git -C ../feature-x status --short
# स्वच्छ वर्क-ट्री हटाएं
git worktree remove ../feature-x
# जांच के बाद जबरन हटाएं
git worktree remove --force ../feature-x
3. भूले हुए पुराने वर्क-ट्री
मैन्युअल रूप से बनाए गए वर्क-ट्री अक्सर उपेक्षित छोड़ दिए जाते हैं, जिससे शाखाएं लॉक रहती हैं और डिस्क स्पेस बर्बाद होता है। यदि किसी डायरेक्टरी को git worktree remove के बजाय rm -rf से हटा दिया जाता है, तो Git अपने रिकॉर्ड में अमान्य संदर्भ बनाए रखता है।
# देखें कि क्या साफ किया जा सकता है
git worktree prune --dry-run --verbose
# पुराने अनुपयोगी संदर्भों को हटाएं
git worktree prune
स्पष्ट नियम यह है: जो प्रणाली वर्क-ट्री बनाती है, उसे कार्य जीवनचक्र के एक निश्चित चरण में उसे पूरी तरह साफ भी करना चाहिए।
Ivy Tendril में वर्क-ट्री का उपयोग
Ivy Tendril एक स्थानीय-प्रथम डेस्कटॉप एप्लिकेशन (macOS, Windows, Linux) है जो योजना से लेकर परखे हुए पुल रिक्वेस्ट तक कोडिंग एजेंटों को चलाता है। वर्क-ट्री इसकी प्राथमिक निष्पादन इकाई हैं। उत्पाद विवरण और जीवनचक्र संदर्भ देखें।
- प्रति योजना एक वर्क-ट्री: जब किसी योजना को स्वीकृति मिलती है, तो Tendril स्वचालित रूप से उसके लिए एक स्वतंत्र वर्क-ट्री और शाखा तैयार करता है। दर्जनों योजनाएं समानांतर में चलती हैं जबकि मुख्य शाखा (main) अछूती रहती है।
- स्वतंत्र सत्यापन: परीक्षण, लिंट और diff की गणना केवल उसी योजना के ट्री में होती है। Review दृश्य में diff और परीक्षण रिपोर्ट साथ-साथ दिखाई जाती हैं।
- मर्ज के बाद स्वतः सफाई: जब GitHub पर पुल रिक्वेस्ट मर्ज हो जाती है, तो Tendril स्वचालित रूप से उस वर्क-ट्री को पूरी तरह हटा देता है।
- एजेंट स्वतंत्रता: वर्क-ट्री के भीतर Claude Code, OpenAI Codex CLI, Copilot CLI, Gemini CLI या OpenCode किसी को भी चलाया जा सकता है।
- 100% स्थानीय सुरक्षा: कोड, योजनाएं और लॉग आपकी अपनी मशीन पर सुरक्षित रहते हैं। लोकल-फर्स्ट AI विकास देखें।
Ivy Tendril के साथ शुरुआत करें
अलगाव और समानांतर AI एजेंटों की शक्ति का अनुभव करें:
- सोर्स कोड देखें: GitHub पर Ivy Tendril का निरीक्षण करें (ओपन सोर्स)।
- तकनीकी गाइड: tendril.ivy.app पर सभी दस्तावेज़ पढ़ें।
- इंजीनियर से चर्चा: 30 मिनट के तकनीकी सत्र के लिए renco@ivy.app पर संपर्क करें।