Claude Code Worktrees: समानांतर कार्य बिना फ़ाइल संघर्ष के

Claude Code सेशन को एक के बाद एक चलाना एक आदत है, आवश्यकता नहीं। जब आपके कार्य वास्तव में स्वतंत्र हों, तो एक को दूसरे के लिए इंतजार करने की कोई वजह नहीं है। Git worktrees प्रत्येक Claude सेशन को अपनी चेक-आउट की गई निर्देशिका देते हैं अपनी शाखा पर, सभी एक ही .git ऑब्जेक्ट स्टोर से खींचते हैं। कोई डुप्लिकेट क्लोन नहीं, कोई फ़ाइल संघर्ष नहीं, जब आप हो जाएँ तब मानक git merge। यह पोस्ट पूरे वर्कफ़्लो के माध्यम से चलती है: कब worktree का उपयोग करें, एक सेटअप करना कैसे है, आप वास्तव में कौन सा अलगाव प्राप्त करते हैं (और कौन सा नहीं), और बिना उस काम को खोए कैसे सफाई करें जो अभी तक प्रतिबद्ध नहीं हुआ है।

कब Worktree मदद करता है

हर कार्य के लिए नहीं। ईमानदार जवाब: worktrees काफी विशिष्ट स्थितियों की एक संकीर्ण श्रेणी में चमकते हैं।

bri द्वारा एक YouTube walkthrough (जून 2026) इसे अच्छी तरह बताता है। एक worktree का उपयोग करें जब आपके पास दो या अधिक कार्य हों जो एक जैसी फ़ाइलें साझा नहीं करते, या जब कोई कार्य इतना जोखिम भरा हो कि आप किसी भी को प्रतिबद्ध करने से पहले दो अलग-अलग दृष्टिकोण देखना चाहते हैं। यदि एक भी कार्य पूरे कोडबेस में फैलता है, एक ही सेशन पर रहें। अन्वेषणात्मक काम के लिए भी यही जाता है जहाँ आप एजेंट को स्वतंत्र रूप से घूमना चाहते हैं।

दूसरा अच्छा उपयोग केस: सट्टा संबंधी काम। तीन worktrees चलाएँ, प्रत्येक को एक ही समस्या के लिए थोड़ा अलग प्रॉम्प्ट दें, और वह संस्करण चुनें जो आपको पसंद है। Zylos Research नोट करता है कि यह पैटर्न चार या अधिक समवर्ती AI सेशन चलाने वाली टीमों पर सामान्य हो गया है, ठीक क्योंकि आप गैर-निर्धारक मॉडल आउटपुट के खिलाफ बचाव कर रहे हैं एक भी बार पर निर्भर करने के बजाय।

इसके विपरीत, यदि आपकी परियोजना में PostgreSQL, Redis, एक बड़ा TypeScript monorepo, कई आंतरिक पैकेज और एक Remix फ्रंटएंड शामिल है, तो अकेले worktrees आपकी समन्वय समस्याओं को हल नहीं करेंगे। Trigger.dev ने बिल्कुल इसी बारे में लिखा और अंततः एक अलग दृष्टिकोण पर चला गया। फ़ाइलसिस्टम अलगाव वास्तविक है। सेवा अलगाव स्वचालित नहीं है।

अलग-थलग कार्य चेकआउट बनाएँ

अपनी आधार शाखा पर शुरू करें और नवीनतम खींचें। फिर .claude/worktrees को अपने .gitignore में एक बार जोड़ें:

echo ".claude/worktrees" >> .gitignore

Claude डिफ़ॉल्ट रूप से आपकी रेपो निर्देशिका के अंदर worktrees रखता है। उस .gitignore प्रविष्टि के बिना, वे अनट्रैक की गई फ़ाइलों के रूप में दिखाई देते हैं और आपकी git status को अस्त-व्यस्त करते हैं। इसे जोड़ें, इसे प्रतिबद्ध करें, इसे भूल जाएँ।

अब प्रति कार्य एक सेशन चलाएँ। दो टर्मिनल खोलें:

claude --worktree feature-payments

``

claude --worktree bugfix-auth

Dan Does Code के लेखन के अनुसार, Claude worktree को .claude/worktrees/feature-payments/ पर बनाता है, एक नई शाखा को चेक आउट करता है, और सेशन को उस निर्देशिका तक सीमित करता है। आपका मुख्य कार्य वृक्ष पूरे समय अछूता रहता है। आप short flag form claude -w feature-payments भी उपयोग कर सकते हैं यदि आप पसंद करते हैं। नाम को पूरी तरह छोड़ दें और Claude स्वचालित रूप से एक उत्पन्न करता है।

प्रत्येक सेशन अब पूर्ण फ़ाइलसिस्टम अलगाव में काम करता है। टर्मिनल 1 का एजेंट उन फ़ाइलों को नहीं छू सकता जिन पर टर्मिनल 2 का एजेंट काम कर रहा है, क्योंकि वे विभिन्न निर्देशिकाओं में विभिन्न शाखाओं पर हैं। वह पूरी चाल है। यह बुनियादी ढांचे-स्तरीय अलगाव है, एजेंटों के बीच समन्वय तर्क नहीं। (यदि आप इसके बजाय उसे चाहते हैं तो Claude Code subagents गाइड ऑर्केस्ट्रेशन पक्ष को कवर करती है।)

प्रत्येक सेशन को इसका कार्य देना

एक बार दोनों सेशन चल रहे हों, प्रत्येक को इसके निर्देश दें। प्रत्येक Claude उदाहरण को एक ताजा संदर्भ के रूप में मानें। दायरे के बारे में विशिष्ट रहें। यदि टर्मिनल 1 एक भुगतान सुविधा बना रहा है, तो इसे बताएँ कि कौन सी फ़ाइलें छूनी हैं और कौन सी नहीं। टर्मिनल 2 के लिए भी यही।

जब सेशन ख़त्म हो, Claude से कहें कि वह branch को push करे और pull request खोले, फिर आप terminal बंद करें। इस तरह का काम आपकी local machine से सुरक्षित रहता है और review के लिए तैयार रहता है।

Dependencies, Ports और Local Configuration को Manage करें

यहीं चीजें मुश्किल हो जाती हैं। Filesystem isolation अपने आप हो जाता है। बाकी सब कुछ को कुछ manual setup की जरूरत है।

Ports। अगर दोनों worktrees dev server को शुरू करते हैं, तो वे default रूप से same port पर टकराएंगे। हल यह है कि हर worktree को अपनी .env फ़ाइल दें जिसमें अलग port assignment हो। कुछ इस तरह — एक में PORT=3001 और दूसरे में PORT=3002। या startup पर inline override pass करें। दोनों काम करते हैं।

Databases। SQLite आसान है: हर worktree की .env को अलग file path की ओर point करें। PostgreSQL या MySQL को ज्यादा सोच की जरूरत है। आपको या तो हर worktree के लिए अलग database instance चाहिए, या कम से कम same instance के अंदर अलग schema/database चाहिए। हर worktree की .env में environment variables के जरिए connection string configure करें। दो agents जो concurrently migrations लिख रहे हैं उन्हें database share न करें। यह corruption या race conditions के लिए कह रहा है।

Local config files। अगर आपका project एक local config file use करता है जो commit नहीं है (जैसे .env.local, config/local.yml), तो आपको हर worktree के लिए एक बनाना होगा। वे main working tree से automatically inherit नहीं होते।

MindStudio की parallel AI coding agents पर guide इन isolation patterns को ज्यादा detail में cover करती है। short version: worktrees design से ही आपको branch और directory isolation देते हैं। Database और port isolation को आपको explicitly, पहले से configure करना पड़ता है।

एक और चीज है जो यहां flag करने लायक है। अगर आप एक ऐसे project पर काम कर रहे हैं जिसका local service setup expensive या complicated है और आप multiple worktrees चला रहे हैं, तो सोचें कि setup cost parallel speedup के लायक है या नहीं। एक library या CLI tool के लिए, बिल्कुल। एक full-stack monorepo के लिए जिसमें छह services हों, तो शायद कम। अगर आपको इसे scope करने में मदद चाहिए, एक Claude Code developer आपके stack के लिए यह assess कर सकता है कि worktrees या कोई अलग parallel strategy fit है या नहीं।

दोनों Branches को Review और Integrate करें

दोनों agents ख़त्म हो गए। दोनों branches push हो गई हैं। अब आप review करें।

यहां का workflow standard git है। parallel setup merge process को बिल्कुल नहीं बदलता। एक typical two-task repo के लिए numbered sequence:

1. main को check out करें और latest को pull करें।
2. पहली branch को review करें। git diff main..feature-payments आपको पूरी तस्वीर देता है कि क्या change हुआ।
3. अगर आप खुश हैं, तो merge करें या main में rebase करें। base branch के साथ conflicts को usual तरीके से resolve करें।
4. main को फिर से pull करें ताकि वह changes आ जाएं।
5. दूसरी branch को review करें। git diff main..bugfix-auth।
6. Merge करें। अगर दोनों agents ने overlapping files को touch किया (जो सही scoping से नहीं होना चाहिए, लेकिन कभी-कभी होता है), तो यहां conflicts को resolve करें।
7. दोनों merges main में आने के बाद अपने test suite को main के खिलाफ चलाएं।

इसे sequentially review करने का फायदा, दोनों को simultaneously merge करने के बजाय, यह है कि एक merge से conflicts दूसरे में नहीं बढ़ते। सरल diffs, आसान reasoning।

बिना Uncommitted Work खोए Clean Up करें

Cleanup वह जगह है जहां developers को घबराहट होती है। अगर एक worktree में कोई काम है जो कभी commit नहीं हुआ?

जवाब: worktree को remove करने से पहले इसे stash कर दें।

यदि आपके पास किसी worktree में uncommitted changes हैं जिन्हें आप सुरक्षित रखना चाहते हैं, तो उस worktree डायरेक्टरी में जाएँ और यह चलाएँ:

git stash push -m "wip: payments feature - pre-cleanup"

यह stash shared .git object store में रहता है, जिसका मतलब है कि यह आपके main working tree या किसी अन्य worktree से accessible है, भले ही original worktree हटा दिया गया हो। एक बार stash करने के बाद, आप safely delete कर सकते हैं:

git worktree remove .claude/worktrees/feature-payments

फिर, अपने main working tree में वापस जाएँ और stash को pop करें:

git stash pop

यदि experiment पूरी तरह fail हो गया है और आप इससे कुछ नहीं चाहते, तो बस stash किए बिना delete करें। git worktree remove --force flag के साथ worktree को हटा देता है भले ही उसमें uncommitted changes हों। --force का उपयोग करने से पहले सुनिश्चित हो जाएँ। कोई recovery path नहीं है।

सभी worktrees हटाने के बाद, list को prune करें ताकि सब कुछ organized रहे:

git worktree prune

यह .git/worktrees/ से किसी भी stale administrative references को हटाता है।

Shared Resources जिन्हें Worktrees Isolate नहीं करते

इस बारे में स्पष्ट रहना महत्वपूर्ण है, क्योंकि "isolation" का mental model आपको mislead कर सकता है।

Worktrees क्या isolate करते हैं:

• Working directory और इसमें सभी files
• वह branch जिस पर प्रत्येक session काम करता है
• Staged और unstaged changes

Worktrees क्या isolate नहीं करते:

• .git object store (design से shared है)
• Machine-local auto memory (official memory docs की confirm करती है कि same-repository worktrees यह share करते हैं)
• External services: databases, queues, caches, कोई भी networked dependency
• Environment credentials और API keys जब तक आप explicitly हर worktree के लिए different values set नहीं करते
• आपके OS-level shell environment में कुछ भी जो दोनों sessions inherit करते हैं

यह security के लिए भी महत्वपूर्ण है। Worktrees कोई tenant boundary नहीं हैं। यदि दोनों sessions same API key या database credentials share करते हैं, तो वे access share करते हैं। किसी Claude session को sensitive local config से sandbox करने के लिए worktree का उपयोग न करें। यह वह नहीं है।

बस filesystem isolation के बजाय एक broader workflow में multiple agents को orchestrate करने के लिए, Claude Code superpowers post wider patterns को समझाता है।

FAQ

क्या `claude --worktree` manually `git worktree add` चलाने के जैसा ही काम करता है?

Functionally similar लेकिन identical नहीं है। claude --worktree git worktree add करता है, branch create करता है, और Claude session को उस directory में scope करता है एक ही step में। यदि आप manually git worktree add चलाते हैं और फिर resulting directory के अंदर Claude start करते हैं, तो आपको same filesystem result मिलता है लेकिन Claude के built-in scoping के बिना। --worktree flag common case के लिए faster path है।

क्या मैं एक साथ दो से अधिक worktrees चला सकता हूँ?

हाँ। git या Claude Code की ओर से worktrees की संख्या पर कोई hard limit नहीं है। व्यावहारिक सीमा आपकी मशीन की RAM और CPU है। एक आधुनिक dev मशीन पर तीन या चार concurrent sessions ठीक है। इससे अधिक और आप git की किसी भी सीमा से पहले resource constraints का सामना करने लगते हैं।

अगर मैं worktree को delete कर दूँ तो उसकी branch का क्या होगा?

Branch बची रहती है। git worktree remove से working directory और .git/worktrees/ में administrative reference delete हो जाता है। Branch खुद बनी रहती है और आपके main working tree या किसी अन्य worktree से accessible होती है। जब आपको इसकी जरूरत न रह जाए तब आप git branch -d branch-name से branch को अलग से delete कर सकते हैं।

क्या worktrees इस बात को प्रभावित करते हैं कि Claude CLAUDE.md project memory को कैसे पढ़ता या लिखता है?

एक ही repository के worktrees official memory documentation के अनुसार machine-local auto memory को share करते हैं। अगर आपके पास CLAUDE.md फ़ाइल repo में committed है, तो हर worktree इसे अपनी checked-out copy से पढ़ता है। एक agent द्वारा अपने worktree में CLAUDE.md में किए गए edits उस branch तक isolated रहते हैं जब तक merged न हो जाएँ। लेकिन machine-local layer shared होती है, इसलिए एक session द्वारा वहाँ लिखी गई instructions दूसरे को दिखाई देती हैं।

क्या worktrees को चलाने का separate clones की तुलना में कोई performance cost है?

Worktrees, clones से सस्ते होते हैं। वे .git object store को share करते हैं, इसलिए disk पर पूरे repository history की कोई duplication नहीं होती। मुख्य cost working directory खुद है, जो branch की current state में सभी tracked files का एक full checkout है। binary assets या generated files वाली बड़ी repos के लिए वह checkout size accumulate हो सकता है। लेकिन git operations (fetch, log, diff) सभी एक single object store के विरुद्ध चलते हैं, इसलिए वे fast होते हैं।

Worktrees को separate clones पर prefer करने का सबसे clear कारण: एक worktree में बनाए गए stashes और refs तुरंत ही उसी repo में हर जगह accessible हो जाते हैं। यह shared state ही वह है जो ऊपर दिए गए cleanup workflow को काम करता है।