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 हटा देता है।

असली सवाल: इन पाँच 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 में संभाल सकते हैं, वो भी दिमाग़ खोए बिना।