Git worktrees: बिना conflict के कई AI agents चलाने की नींव

आप एक ही repo पर दो agents चला देते हैं। एक package.json एडिट करता है, दूसरा भी वही करता है। तीस सेकंड बाद आपका code ऐसी हालत में होता है जिसे कोई merge नहीं कर सकता।

ये आपके agents का bug नहीं है। दिक्कत ये है कि वे सब एक ही folder में काम कर रहे हैं।

इसका हल एक ऐसा tool है जो Git में सालों से मौजूद है और जिसे लगभग कोई इस्तेमाल नहीं करता: git worktree।

समस्या: 3 agents, 1 repo, और merge करना नामुमकिन

एक आम Git repo यानी एक folder, जिसमें एक बार में एक ही branch checked out होती है। आप main पर काम करते हैं, branch बदलते हैं, और पूरा folder पलट जाता है।

अब उसी folder में तीन autonomous agents डाल दीजिए। वे एक साथ लिखते हैं। Agent A एक file बनाता है, agent B साफ़ शुरुआत के लिए git checkout चलाता है और A का चल रहा काम मिटा देता है। आखिर में आपके पास आधी-अधूरी files रह जाती हैं, index बर्बाद हो जाता है, और ऐसे conflicts खड़े हो जाते हैं जिन्हें सुलझाने में खुद code लिखने से ज़्यादा वक़्त लग जाता है।

Parallelism आपका वक़्त तभी बचाता है जब agents एक-दूसरे के काम को न छुएँ।

Git worktree होता क्या है

Worktree एक दूसरा working folder है जो उसी repo से जुड़ा होता है।

History वही, remote वही, लेकिन हर worktree की अपनी branch checked out होती है और disk पर अपनी files होती हैं। आप पाँच worktrees साथ-साथ रख सकते हैं, हर एक अलग branch पर, और वे एक-दूसरे के रास्ते में नहीं आते।

एक .git, कई workspaces। बस इतना ही।

व्यवहार में: हर agent के लिए एक worktree

setup ऐसे होता है। अपने repo से:

git worktree add ../project-auth -b feature/auth
git worktree add ../project-billing -b feature/billing
git worktree add ../project-export -b feature/export

आपने अभी तीन folders बना दिए, हर एक अपनी branch पर। अब हर folder में एक agent शुरू कर दीजिए:

cd ../project-auth && claude
cd ../project-billing && codex

हर agent के पास अपना folder, अपनी branch, अपनी files हैं। Auth वाला agent कभी नहीं देखेगा कि billing वाला agent क्या कर रहा है। कोई टकराव मुमकिन ही नहीं।

जब कोई feature तैयार हो जाए, तो आप उसकी branch review करके merge कर लीजिए। फिर सफाई:

git worktree remove ../project-auth

Folder हट गया, branch आपकी history में बनी रहती है। एकदम साफ़।

जानने लायक 3 जाल

पहला जाल, साझा central file। अगर दो features दोनों को एक ही routes.ts या एक ही database schema छूना पड़े, तो worktrees आपको नहीं बचाएँगे, merge के वक़्त conflict मिल ही जाएगा। एक agent उन files को छुए जो सबमें साझा हैं, बाकी या तो इंतज़ार करें या कोई दूसरा रास्ता निकालें।

दूसरा, branches का बहक जाना। जब तक आपके agents काम करते हैं, main आगे बढ़ता रहता है। तीन दिन बाद आपकी branches पीछे रह जाती हैं और merge करना सिरदर्द बन जाता है। जल्दी-जल्दी rebase करते रहिए, या sessions छोटे रखिए।

तीसरा, सफाई भूल जाना। हर worktree आपकी disk पर एक असली folder है। दिन में दस बनाए और सफाई नहीं की, तो आपका parent folder पढ़ने लायक ही नहीं रहेगा। git worktree list दिखाता है कि क्या-क्या पड़ा है, और git worktree prune मरे हुए worktrees हटा देता है।

चौथा जाल: worktree खाली शुरू होता है

Worktree में सिर्फ़ वही files होती हैं जिन्हें Git track करता है। git worktree add आपको source code देता है, node_modules नहीं, .venv नहीं, आपके local secrets वाली .env नहीं, build cache नहीं। नए worktree में शुरू होने वाला agent tests नहीं चला सकता, dev server शुरू नहीं कर सकता, और अक्सर यह भी नहीं बताता कि क्यों: npm test किसी missing module पर fail होता है, app किसी गायब environment variable पर fail होता है, और agent अपने पहले दस मिनट ticket की जगह setup की उलझनों में लगा देता है।

यह जाल हमें भी लगा। एक user ने बताया कि AgentsRoom में worktree का option agent form के advanced options में छिपा था, और worktree में शुरू किए गए किसी भी agent के पास एक भी dependency नहीं होती थी और वह एक भी test नहीं चला पाता था। दोनों बातें सच थीं। अलगाव मौजूद था, लेकिन एक manual step के बिना किसी काम का नहीं था, और वह step किसी को याद नहीं रहता था।

Version 1.194.0 से यह option agent form के "अलगाव" block में है, बिना कुछ खोले दिखता है, और नए worktree में शुरू होने वाले पहले agent को वह तैयार मिलता है: AgentsRoom main checkout से वे ignored files copy करता है जो किसी pattern से मेल खाती हैं (default रूप से हर .env*, कभी overwrite नहीं करता, कभी node_modules या .git के अंदर नहीं), फिर lockfile से पहचाना गया install command चलाता है (bun, pnpm, yarn, npm, uv, poetry, pipenv, bundle, composer) या वह command जो आपने project settings में सेट किया है। Command agent के अपने terminal में चलता है, इसलिए आप उसे देखते हैं, और install fail होने पर भी agent शुरू होने से नहीं रुकता। यह हर worktree के लिए एक बार होता है: worktree के private git folder में रखा एक marker पक्का करता है कि अगले launch पर यह step छोड़ दिया जाए।

अगर आप यह हाथ से करते हैं, तो recipe वही है और एक script में आ जाती है: .env* copy करें, install चलाएँ, फिर agent शुरू करें। git worktree add को इसी script में लपेट दीजिए, वरना तीसरे agent तक आप इसे भूल जाएँगे।

असली सवाल: इन पाँच folders पर नज़र कौन रखेगा?

Worktrees file conflicts हल कर देते हैं। लेकिन आपका mental load हल नहीं करते।

आपके पास पाँच folders हैं, पाँच agents हैं, पाँच terminals हैं। कौन सा आपके review का इंतज़ार कर रहा है? कौन सा दस मिनट पहले ख़त्म हो गया जब आपका ध्यान कहीं और था? कौन सा crash हो गया?

यहीं पर हर agent के लिए एक worktree वाला तरीका अपनी हद तक पहुँच जाता है, अगर आप terminal में ही टिके रहें। तकनीकी conflict तो आपने हल कर लिया, लेकिन नज़र रखने वाली windows बढ़ा लीं।

AgentsRoom हर agent को एक tile पर रखता है, उसके status और color के साथ, चाहे वह किसी भी worktree में चल रहा हो। जो agent इंतज़ार कर रहा है वह लाल हो जाता है और आपको ping करता है। worktrees के ऊपर का पूरा तरीका जानने के लिए पढ़िए 3 से 8 agents को parallel में बिना भटके कैसे चलाएँ।

निचोड़

एक agent, एक worktree, एक branch। गंभीर multi-agent काम का यही बुनियादी नियम है।

Commands तीन lines में आ जाती हैं, और फ़ायदा तुरंत मिलता है: आपके agents एक-दूसरे का काम overwrite करना बंद कर देते हैं। ऊपर से एक ऐसा view जोड़ दीजिए जो बता दे कि किसको आपकी ज़रूरत है, और फिर आप सच में पाँच काम parallel में संभाल सकते हैं, वो भी दिमाग़ खोए बिना।