Git Worktree ट्यूटोरियल: बिना स्विच किए कई ब्रांच पर काम करें

आप किसी फीचर ब्रांच पर काम कर रहे हैं, तभी आपका साथी आपसे उनकी पुल रिक्वेस्ट रिव्यू करने को कहता है। आप चाहें तो अपने बदलावों को स्टैश करें, ब्रांच स्विच करें, और उम्मीद करें कि आपको याद रहे आप कहाँ तक पहुँचे थे। या फिर सिर्फ़ बचाने के लिए अधूरा काम कमिट कर दें। फिर आता है इमरजेंसी हॉटफ़िक्स: प्रोडक्शन डाउन है और आप ऐसे रिफैक्टरिंग के बीच में हैं जो आधे कोडबेस को छू रही है। इस तरह हर कॉन्टेक्स्ट स्विच में 10–15 मिनट का सेटअप समय लगता है और आपका फोकस टूटता है।

Git worktree इसका हल देता है—यह आपको अलग-अलग डायरेक्टरी में एक ही समय पर कई ब्रांच चेकआउट करने देता है। अधूरा काम स्टैश या कमिट करने के बजाय, आप बस cd करके उस दूसरी डायरेक्टरी में चले जाएँ जहाँ कोई और ब्रांच पहले से चेकआउट है। हॉटफ़िक्स पर काम करें, उसे डिप्लॉय करें, फिर cd करके अपनी फीचर ब्रांच पर ठीक उसी स्थिति में वापस आ जाएँ जैसी आपने छोड़ी थी।

इस ट्यूटोरियल में, मैं आपको बताऊँगा कि worktrees कैसे बनाते और मैनेज करते हैं, आम गलतियों से कैसे बचते हैं, और उन्हें अपने दैनिक वर्कफ़्लो में कैसे शामिल करते हैं। आपको पहले से Git की ब्रांच, कमिट, और बेसिक कमांड-लाइन ऑपरेशनों की समझ होनी चाहिए। अगर आपको पहले Git की बुनियादी बातें दोहरानी हैं, तो मैं DataCamp के Introduction to Git ट्यूटोरियल की सलाह दूँगा जो ज़रूरी बातें कवर करता है।

Git Worktree क्या है?

Git worktree एक बिल्ट-इन फ़ीचर है जो उसी रिपॉज़िटरी से जुड़ी अतिरिक्त वर्किंग डायरेक्टरियाँ बनाता है। आपकी मुख्य वर्किंग डायरेक्टरी प्राइमरी worktree होती है, और आप जो भी अतिरिक्त worktree बनाते हैं, उन्हें अपनी-अपनी डायरेक्टरी और उन पर चेकआउट की गई अपनी-अपनी ब्रांच मिलती है। ये सभी worktrees एक ही .git रिपॉज़िटरी से जुड़े रहते हैं।

इस साझा रिपॉज़िटरी आर्किटेक्चर का मतलब है कि आप किसी भी worktree में जो कमिट करते हैं, वे तुरंत साझा Git डेटाबेस में दिखते हैं और बाकी सभी worktrees से सुलभ होते हैं। फ़ाइलें खुद स्वतंत्र रहती हैं—एक worktree में train.py एडिट करने से तब तक सिर्फ़ वही डायरेक्टरी प्रभावित होती है जब तक आप बदलाव कमिट न कर दें।

सिर्फ़ अलग-अलग टर्मिनल क्यों नहीं?

आप एक ही डायरेक्टरी में कई टर्मिनल खोलकर अलग-अलग ब्रांच पर साथ-साथ काम नहीं कर सकते। Git प्रति डायरेक्टरी केवल एक ब्रांच चेकआउट करने देता है। जब आप किसी एक टर्मिनल में git checkout feature-b चलाते हैं, तो उस डायरेक्टरी की ओर इशारा करने वाले हर टर्मिनल के लिए फ़ाइलें बदल जाती हैं।

Git worktree हर ब्रांच के लिए अलग डायरेक्टरी दे कर इसे हल करता है। हर डायरेक्टरी अपनी फ़ाइलों, चल रही प्रक्रियाओं, और बिल्ड आर्टिफैक्ट्स के साथ पूरी तरह स्वतंत्र होती है। ब्रांच स्विच करना git checkout different-branch के बजाय cd ../different-directory बन जाता है।

Git Worktree के लिए पूर्वापेक्षाएँ

git worktree उपयोग करने से पहले अपनी सेटअप जाँचें:

• Git 2.5 या बाद का: जाँचने के लिए git --version चलाएँ। Git worktree 2015 में आया था, इसलिए अधिकांश इंस्टॉलेशनों में यह मौजूद रहता है
• मौजूदा Git रिपॉज़िटरी: आपको कम-से-कम एक ब्रांच वाली रिपॉज़िटरी चाहिए
• कमांड-लाइन की जानकारी: सभी worktree ऑपरेशन टर्मिनल में होते हैं

देखें कि worktree उपलब्ध है या नहीं:

git worktree --helpसंचालित द्वारा

यदि यह हेल्प पेज दिखाता है, तो आप तैयार हैं।

git worktree कब उपयोग करें

जब ब्रांच स्विच करना आपके मौजूदा काम में खलल डाले, तब Git worktree अच्छा काम करता है:

• कोड रिव्यू: अपने फीचर काम को स्टैश किए बिना टीममेट के बदलाव टेस्ट करें
• इमरजेंसी हॉटफ़िक्स: अपनी रिफैक्टरिंग को छुए बिना प्रोडक्शन बग्स फिक्स करें
• समानांतर डेवलपमेंट: लगातार ब्रांच स्विच किए बिना दो स्वतंत्र फीचर्स पर काम करें
• लंबी चलने वाली प्रक्रियाएँ: 30-मिनट की टेस्ट सूट शुरू करें और दूसरे worktree में कोडिंग जारी रखें

10 मिनट से कम के त्वरित कार्यों के लिए इसे छोड़ दें जहाँ git checkout सरल है, या जब आप बिना व्यवधान के किसी एक काम पर केंद्रित हों।

अपना पहला Worktree बनाना

git worktree को समझने का सबसे अच्छा तरीका है एक worktree बनाना और उसे चलते देखना। हम बेसिक कमांड्स से गुज़रेंगे, Git जो संरचना बनाता है उसे देखेंगे, और देखेंगे कि बदलाव worktrees के बीच कैसे बहते हैं।

एक सैंपल रिपॉज़िटरी सेटअप करना

worktrees में उतरने से पहले, आपको एक Git रिपॉज़िटरी चाहिए। यदि आपके पास पहले से कई ब्रांच वाला Python प्रोजेक्ट है, तो अगले सेक्शन पर जाएँ। अन्यथा, एक सरल ML पाइपलाइन जल्दी से सेट करें:

mkdir ml-pipeline
cd ml-pipeline
git initसंचालित द्वारा

एक README और एक Python स्क्रिप्ट बनाएँ:

echo "# ML Pipeline" > README.md
echo "def load_data():" > train.py
echo "    print('Loading training data...')" >> train.pyसंचालित द्वारा

जाँचें कि फ़ाइलें बन गई हैं:

ls
# You should see: README.md  train.pyसंचालित द्वारा

इन फ़ाइलों को कमिट करें और एक फीचर ब्रांच बनाएँ:

git add .
git commit -m "Initial commit"
git branch feature-preprocessingसंचालित द्वारा

अब आपके पास दो ब्रांच वाली रिपॉज़िटरी है: main (आपकी मौजूदा ब्रांच) और feature-preprocessing।

बेसिक worktree बनाना

किसी मौजूदा ब्रांच के लिए worktree बनाना एक ही कमांड से हो जाता है। चलिए feature-preprocessing को अलग डायरेक्टरी में चेकआउट करते हैं:

git worktree add ../ml-pipeline-preprocessing feature-preprocessingसंचालित द्वारा

यह आपकी मौजूदा लोकेशन से एक लेवल ऊपर ml-pipeline-preprocessing नाम की नई डायरेक्टरी बनाता है, वहाँ feature-preprocessing ब्रांच चेकआउट करता है, और उसे आपकी मौजूदा रिपॉज़िटरी से लिंक कर देता है।

Git निर्माण की पुष्टि करता है:

Preparing worktree (checking out 'feature-preprocessing')
HEAD is now at 0a7f986 Initial commitसंचालित द्वारा

बिलकुल नए काम के लिए, एक साथ ब्रांच और worktree दोनों बनाएँ:

git worktree add -b feature-visualization ../ml-pipeline-vizसंचालित द्वारा

यहाँ -b फ्लैग feature-visualization नाम की नई ब्रांच बनाता है और उसे नए worktree में चेकआउट करता है।

worktree संरचना को समझना

worktree बनने के बाद, अब आपके फ़ाइल सिस्टम में कई डायरेक्टरियाँ हैं। उन्हें सब देखने के लिए:

git worktree listसंचालित द्वारा

/Users/you/projects/ml-pipeline                  0a7f986 [main]
/Users/you/projects/ml-pipeline-preprocessing    0a7f986 [feature-preprocessing]संचालित द्वारा

पहली लाइन आपका मुख्य worktree दिखाती है—वही मूल डायरेक्टरी जिसमें .git फ़ोल्डर होता है। दूसरी लाइन आपका लिंक्ड worktree दिखाती है। दोनों मौजूदा कमिट हैश और चेकआउट की गई ब्रांच दिखाते हैं।

हर worktree डायरेक्टरी एक पूर्ण Git रिपॉज़िटरी जैसी काम करती है। आप इसमें जा सकते हैं, फ़ाइलें एडिट कर सकते हैं, git status चला सकते हैं, और कमिट कर सकते हैं। लिंक्ड worktrees में पूरा .git डायरेक्टरी नहीं होता—इसके बजाय, उनमें एक .git फ़ाइल होती है जो मुख्य रिपॉज़िटरी की ओर इंगित करती है। मुख्य .git डायरेक्टरी के अंदर, एक worktrees फ़ोल्डर हर लिंक्ड worktree का मेटाडेटा स्टोर करता है।

किसी worktree में काम करना

feature-preprocessing worktree में जाएँ और एक कमिट करें:

cd ../ml-pipeline-preprocessing
cat >> train.py << 'EOF'

def preprocess_features(df):
   """Normalize numeric features."""
   return (df - df.mean()) / df.std()
EOF
git add train.py
git commit -m "Add feature preprocessing function"संचालित द्वारा

कमिट सामान्य रूप से हो जाता है:

[feature-preprocessing 7c8d4e2] Add feature preprocessing function
1 file changed, 3 insertions(+)संचालित द्वारा

अपने मुख्य worktree में लौटें और कमिट हिस्ट्री देखें:

cd ../ml-pipeline
git log --oneline --allसंचालित द्वारा

आपका नया कमिट दिखेगा:

7c8d4e2 Add feature preprocessing function
0a7f986 Initial commitसंचालित द्वारा

ध्यान दें कि बिना किसी अतिरिक्त कमांड के कमिट तुरंत दोनों जगह दिखता है।

Git Worktree के उपयोग के मामले

अब जब आप जानते हैं कि worktrees कैसे बनाएँ और उनमें काम करें, तो आइए व्यावहारिक परिदृश्यों को देखें जहाँ वे वास्तविक डेवलपमेंट समस्याएँ हल करते हैं।

कोड रिव्यू वर्कफ़्लो

आपके टीममेट को उनकी PR पर फ़ीडबैक चाहिए। अपने बदलाव स्टैश करने और ब्रांच स्विच करने के बजाय, रिव्यू के लिए अलग डायरेक्टरी बनाएँ:

git worktree add ../ml-pipeline-review pr/update-training
cd ../ml-pipeline-review
pip install -r requirements.txt
python train_model.py --config experiments/baseline.yamlसंचालित द्वारा

बदलावों को टेस्ट करें और अपना फ़ीडबैक दें। काम हो जाने पर:

cd ../ml-pipeline
git worktree remove ../ml-pipeline-reviewसंचालित द्वारा

आपका मूल काम जस का तस रहता है। न स्टैशिंग की ज़रूरत, न कॉन्टेक्स्ट स्विचिंग। प्रभावी कोड रिव्यू की और रणनीतियों के लिए, DataCamp का कोड बेस्ट प्रैक्टिसेज गाइड देखें।

इमरजेंसी हॉटफ़िक्स

बिना worktrees के:

• अपनी रिफैक्टरिंग के बदलाव कहीं सहेजें (स्टैश या WIP कमिट)
• main ब्रांच चेकआउट करें
• बग फिक्स करें
• प्रोडक्शन पर पुश करें
• फिर फ़ीचर ब्रांच चेकआउट करें
• अपने बदलाव वापस लाएँ (अनस्टैश या WIP कमिट रिवर्ट)
• जो कर रहे थे उसका मानसिक संदर्भ फिर स्थापित करें

worktrees के साथ:

git worktree add ../ml-pipeline-hotfix main
cd ../ml-pipeline-hotfixसंचालित द्वारा

फिक्स करें और डिप्लॉय करें:

git add src/data/validation.py
git commit -m "Fix schema validation for nullable timestamp fields"
git push origin main
cd ../ml-pipeline
git worktree remove ../ml-pipeline-hotfixसंचालित द्वारा

आप चंद सेकंड में अपनी रिफैक्टरिंग पर वापस आ जाते हैं, सभी फ़ाइलें ठीक वैसी ही रहती हैं जैसी आपने छोड़ी थीं।

समानांतर फीचर डेवलपमेंट

आप कस्टम मेट्रिक्स और नया डेटा लोडर—दो स्वतंत्र फीचर्स—इम्प्लीमेंट कर रहे हैं। प्रत्येक के लिए एक worktree सेट करें:

git worktree add -b feature-custom-metrics ../ml-pipeline-metrics
git worktree add -b feature-streaming-loader ../ml-pipeline-loaderसंचालित द्वारा

अब आपका फ़ाइल सिस्टम कुछ ऐसा दिखता है:

~/projects/
 ml-pipeline/           [main] - your usual work
 ml-pipeline-metrics/   [feature-custom-metrics]
 ml-pipeline-loader/    [feature-streaming-loader]संचालित द्वारा

दोनों फीचर्स समानांतर में चलाएँ—हर एक अपने टर्मिनल में:

# Terminal 1
cd ~/projects/ml-pipeline-metrics
python experiments/evaluate_custom_metrics.py

# Terminal 2 
cd ~/projects/ml-pipeline-loader
pytest tests/test_data_loader.py -vसंचालित द्वारा

दोनों प्रक्रियाएँ बिना टकराव के साथ-साथ चलती हैं। जब कोई फीचर पूरा हो जाए, उसे मर्ज करें और worktree हटा दें:

cd ~/projects/ml-pipeline
git merge feature-custom-metrics
git worktree remove ../ml-pipeline-metricsसंचालित द्वारा

Worktrees को मैनेज और साफ़ करना

worktrees की सूची देखना

किसी रिपॉज़िटरी में सभी worktrees देखने के लिए:

git worktree listसंचालित द्वारा

/Users/you/projects/ml-pipeline                  a3f9c81 [main]
/Users/you/projects/ml-pipeline-review           b7d4e92 [pr/data-validation]
/Users/you/projects/ml-pipeline-hotfix           a3f9c81 [hotfix/schema-bug]संचालित द्वारा

हर लाइन डायरेक्टरी पाथ, मौजूदा कमिट हैश, और चेकआउट की गई ब्रांच दिखाती है। पहला एंट्री हमेशा आपका मुख्य worktree होता है (जो .git फ़ोल्डर रखता है), और बाकी लिंक्ड worktrees होते हैं।

स्क्रिप्टिंग या तेज़ नेविगेशन के लिए, सिर्फ़ पाथ निकालें:

git worktree list | awk '{print $1}'संचालित द्वारा

worktrees हटाना

जब आप किसी worktree में काम पूरा कर लें, तो उसे ठीक से हटाएँ:

cd ~/projects/ml-pipeline
git worktree remove ../ml-pipeline-reviewसंचालित द्वारा

Git डेटा लॉस से बचाता है। यदि आपके पास अनकमीटेड बदलाव हों:

git worktree remove ../ml-pipeline-reviewसंचालित द्वारा

fatal: '../ml-pipeline-review' contains modified or untracked files, use --force to delete itसंचालित द्वारा

यदि आप निश्चित हैं, तो फोर्स रिमूवल करें:

git worktree remove --force ../ml-pipeline-reviewसंचालित द्वारा

यदि कोई worktree लॉक्ड हो, तो --force दो बार उपयोग करें:

git worktree remove --force --force ../ml-pipeline-lockedसंचालित द्वारा

यदि आपने किसी worktree डायरेक्टरी को मैन्युअली डिलीट कर दिया (rm -rf या फ़ाइल मैनेजर से), तब भी Git उसे आंतरिक रूप से ट्रैक करता है। बासी रेफ़रेंसेज़ साफ़ करें:

git worktree pruneसंचालित द्वारा

क्या प्रून होगा, पहले देखें:

git worktree prune --dry-runसंचालित द्वारा

सर्वोत्तम प्रथाएँ और आम गलतियाँ

आइए देखें कि worktrees का अधिकतम लाभ कैसे उठाएँ और कुछ आम गलतियों से कैसे बचें। 

worktree संगठन

आप worktrees कहाँ रखते हैं, यह मायने रखता है। अधिकांश डेवलपर्स उन्हें मुख्य रिपॉज़िटरी की सिब्लिंग डायरेक्टरियों के रूप में रखते हैं:

~/projects/
 ml-pipeline/                    # main worktree
 ml-pipeline-feature-auth/       # linked worktree
 ml-pipeline-hotfix-login/       # linked worktreeसंचालित द्वारा

यह संरचना सब कुछ एक जगह रखती है और पाथ्स पूर्वानुमेय बनाती है। projectname-branchname पैटर्न आपको तुरंत बता देता है कि हर डायरेक्टरी में क्या है।

कुछ डेवलपर्स एक समर्पित फ़ोल्डर पसंद करते हैं:

~/projects/
 ml-pipeline/                    # main worktree
 ml-pipeline-worktrees/
   feature-auth/
   hotfix-login/संचालित द्वारा

कोई एक तरीका चुनें और लगातार अपनाएँ। ml-pipeline-user-authentication जैसे वर्णनात्मक नाम डायरेक्टरियों को स्वयं-वर्णनात्मक बनाते हैं, जबकि ml-pipeline-temp या ml-pipeline-2 जैसे सामान्य नाम आपको अंदर क्या है, यह जाँचने पर मजबूर करते हैं। worktrees को अस्थायी मानें—किसी विशेष कार्य के लिए बनाएँ, और काम पूरा होने पर हटा दें।

आम गलतियाँ

एक ही ब्रांच कई worktrees में

Git एक ही ब्रांच को दो worktrees में चेकआउट करने से रोकता है:

git worktree add ../ml-pipeline-duplicate mainसंचालित द्वारा

fatal: 'main' is already used by worktree at '/Users/you/projects/ml-pipeline'संचालित द्वारा

यह सुरक्षा इसलिए है क्योंकि आप टकराने वाले कमिट्स कर सकते थे। यदि आपको एक ही कोड दो जगह चाहिए, तो नई ब्रांच बनाएँ।

भूले हुए worktrees और डिस्क स्पेस

हर worktree तब तक आपके फ़ाइल सिस्टम पर रहता है जब तक आप उसे स्पष्ट रूप से हटाते नहीं। पुराने worktrees जमा होते जाते हैं; प्रोजेक्ट्स में 15+ भूले हुए worktrees हो सकते हैं, जो गीगाबाइट्स खा जाते हैं।

हर worktree में आपकी रिपॉज़िटरी की फ़ाइलों की पूरी कॉपी होती है। 500MB की रिपॉज़िटरी और 5 worktrees मिलकर 2.5GB ले लेते हैं। काम पूरा होने पर worktrees हटा दें:

git worktree list
git worktree remove ../ml-pipeline-old-featureसंचालित द्वारा

worktrees को नेस्ट करना

किसी worktree की डायरेक्टरी के अंदर दूसरा worktree न बनाएँ। Git इसकी अनुमति देता है, पर इससे डायरेक्टरी संरचना भ्रमित हो जाती है और सफ़ाई जोखिमभरी।

वर्कफ़्लो अनुकूलन

यदि आप अक्सर worktrees बनाते हैं, तो शेल एलियास समय बचाते हैं:

alias gwl='git worktree list'
alias gwa='git worktree add'
alias gwr='git worktree remove'संचालित द्वारा

ज़्यादा जटिल सेटअप के लिए, एक फ़ंक्शन लिखें जो एक ही चरण में worktree बनाए और आपका डेवलपमेंट वातावरण कॉन्फ़िगर करे:

wt() {
 git worktree add "../${PWD##*/}-$1" -b "$1"
 cd "../${PWD##*/}-$1"
 python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
}संचालित द्वारा

यहाँ ${PWD##*/} आपके मौजूदा डायरेक्टरी नाम को निकालता है। ml-pipeline से wt feature-logging चलाने पर ml-pipeline-feature-logging बनता है, उसमें नेविगेट होता है, और डिपेंडेंसीज़ के साथ Python वर्चुअल एन्वायरनमेंट सेट करता है।

worktree बनाना एक ही कमांड बन जाता है:

wt feature-custom-metricsसंचालित द्वारा

इसे अपनी भाषा/स्टैक के अनुसार ढालें: Ruby के लिए bundle install, Rust के लिए cargo build, या Node.js के लिए npm install चलाएँ।

आपका एडिटर या IDE बिना किसी विशेष कॉन्फ़िगरेशन के worktrees के साथ काम करता है। हर worktree एक साधारण डायरेक्टरी है, इसलिए इसे किसी भी अन्य प्रोजेक्ट फ़ोल्डर की तरह खोलें। अधिकांश आधुनिक एडिटर्स एक साथ कई प्रोजेक्ट रूट खोलने का समर्थन करते हैं—आप एक विंडो में तीन worktrees खोलकर साइडबार में उनके बीच स्विच कर सकते हैं।

एडवांस्ड Worktrees: AI-सहायता प्राप्त समानांतर विकास

यदि आप AI कोडिंग असिस्टेंट्स का उपयोग करते हैं, तो worktrees एक शक्तिशाली समानांतर वर्कफ़्लो अनलॉक करते हैं। यह तरीका 2024–2025 में डेवलपर्स और टीमों के बीच लोकप्रिय हुआ है।

अलग-अलग कार्यों के लिए अलग worktrees बनाएँ:

git worktree add -b feature-add-logging ../ml-pipeline-logging
git worktree add -b feature-optimize-preprocessing ../ml-pipeline-optim
git worktree add -b bugfix-memory-leak ../ml-pipeline-bugfixसंचालित द्वारा

हर worktree के लिए एक-एक टर्मिनल पेन खोलें और अपना AI असिस्टेंट शुरू करें:

# Pane 1
cd ~/projects/ml-pipeline-logging
claude

# Pane 2
cd ~/projects/ml-pipeline-optim
claude

# Pane 3
cd ~/projects/ml-pipeline-bugfix
claudeसंचालित द्वारा

हर AI इंस्टेंस अलग फीचर पर बिना दखल के काम करता है। टीमें बताती हैं कि जो काम पहले दिनों में होता था, वह अब घंटों में पूरा होता है। उदाहरण के लिए, incident.io 4–5 Claude Code एजेंट्स को समानांतर में चलाता है। एक मामले में, Claude ने किसी UI सुधार में 2 घंटे लगने का अनुमान लगाया था, पर 10 मिनट में पूरा कर दिया।

सोचने योग्य ट्रेडऑफ़्स:

• टोकन खपत: कई AI सेशंस ज़्यादा API क्रेडिट्स उपयोग करते हैं और रेट लिमिट तक पहुँच सकते हैं
• सेटअप ओवरहेड: हर worktree को अपना वर्चुअल एन्वायरनमेंट और डिपेंडेंसीज़ चाहिए
• संज्ञानात्मक बोझ: अलग-अलग कार्यों में कई बातचीत मैनेज करना

यह बड़े, स्वतंत्र फीचर्स (प्रत्येक 30+ मिनट) के लिए अच्छा काम करता है जहाँ काम एक ही फ़ाइलों को नहीं छूता और आपके पास पर्याप्त API कोटा है। त्वरित बग फिक्स, कड़े-तौर पर जुड़े फीचर्स, या जब आप API रेट लिमिट के करीब हों, तब इसे छोड़ दें।

निष्कर्ष

शुरुआत वाला परिदृश्य याद है—टीममेट को PR रिव्यू चाहिए और आप बीच फीचर में हैं। अब समाधान आप जानते हैं: git worktree add ../ml-pipeline-review pr/branch-name, फिर रिव्यू शुरू करने के लिए cd करें। आपका फीचर काम अछूता रहता है। न स्टैशिंग, न अधूरा कोड कमिट करना, न वापस लौटते समय मानसिक संदर्भ फिर से बनाने का बोझ। दो डायरेक्टरी, दो ब्रांच, शून्य घर्षण।

Git worktree आपके वर्कफ़्लो में जटिलता नहीं जोड़ता—यह उसे हटाता है। हर worktree बस एक डायरेक्टरी है जिसमें कोई ब्रांच चेकआउट है। लेकिन यही सादगी एक शक्तिशाली चीज़ अनलॉक करती है: कार्यों के बीच तुरंत कॉन्टेक्स्ट-स्विच करने की क्षमता, बिना स्टैशिंग, चेकआउट करने और अपने मानसिक मॉडल को फिर से बनाने के संज्ञानात्मक बोझ के। 

जब आपको worktrees को टीम सहयोग वर्कफ़्लोज़—जैसे पुल रिक्वेस्ट और कोड रिव्यू—के साथ एकीकृत करना हो, तो DataCamp का GitHub Foundations स्किल ट्रैक वितरित टीमों के साथ प्रभावी ढंग से काम करने के लिए आवश्यक प्रथाएँ कवर करता है।