Git Switch Branch: व्यावहारिक उदाहरणों के साथ मार्गदर्शिका

मौजूदा ब्रांचों के नाम कैसे जानें

यदि हम उपलब्ध ब्रांचों की सूची देखना चाहते हैं, तो हम git branch कमांड का उपयोग करते हैं। वर्तमान ब्रांच के आगे एक तारांकन चिह्न लगा होगा। उदाहरण के लिए, यदि हमारे पास तीन लोकल ब्रांचें main, feature-x, और bug-z हैं, और हम वर्तमान में main ब्रांच पर हैं, तो आउटपुट कुछ ऐसा होगा:

* main
feature-x
bug-zसंचालित द्वारा

रिमोट ब्रांच पर स्विच करना

पिछला कमांड हमें किसी ऐसी ब्रांच पर जाने देता है जो हमारे लोकल मशीन पर पहले से हो। रिमोट रिपॉजिटरी की ब्रांच पर स्विच करने के लिए, हमें उसकी एक लोकल प्रति बनानी पड़ती है, इसके लिए यह कमांड उपयोग करें:

git switch -c <local-branch-name> origin/<remote-branch-name>संचालित द्वारा

यहाँ <local-branch-name> वह नाम है जो हम ब्रांच को लोकल रूप से देना चाहते हैं, जबकि <remote-branch-name> रिमोट ब्रांच का नाम है। आम तौर पर भ्रम से बचने के लिए हम वही नाम रखना चाहते हैं। मान लें हमारे पास लोकल में feature-x ब्रांच नहीं है। तब हम इस तरह उसकी लोकल प्रति बनाकर उस पर स्विच कर सकते हैं:

git switch -c feature-x origin/feature-xसंचालित द्वारा

एक ही नाम का उपयोग करने पर Git --track विकल्प के साथ कमांड का संक्षिप्त रूप देता है। तो ऊपर का कमांड इसके बराबर है:

git switch --track origin/feature-xसंचालित द्वारा

रिमोट ब्रांचों की सूची देखने के लिए हम git branch -r कमांड का उपयोग कर सकते हैं।

लोकल रिपॉजिटरी रिमोट ब्रांचों का स्वतः ट्रैक नहीं रखती। इसलिए, रिमोट ब्रांच को सूचीबद्ध करने या उस पर स्विच करने से पहले git fetch का उपयोग करके लोकल रिपॉजिटरी को अपडेट करना महत्वपूर्ण है।

नई ब्रांच बनाना और उस पर स्विच करना

यदि हम किसी नई फीचर पर काम शुरू करने के लिए एक बिल्कुल नई ब्रांच बनाना चाहते हैं, तो इस स्थिति में हम -c फ्लैग का उपयोग कर सकते हैं:

git switch -c <new-branch-name>संचालित द्वारा

हम <new-branch-name को ब्रांच के नाम से बदलते हैं। उदाहरण के लिए, feature-y नाम की ब्रांच बनाने के लिए हम यह करते हैं:

git switch -c feature-yसंचालित द्वारा

पिछली ब्रांच पर वापस स्विच करना

अक्सर ऐसा होता है कि कुछ काम करने के लिए ब्रांच बदलने के बाद, हम उस ब्रांच पर वापस जाना चाहते हैं जिस पर पहले काम कर रहे थे। Git इसके लिए एक शॉर्टहैंड प्रदान करता है:

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

Git Switch बनाम Git Checkout

git checkout कमांड Git में शुरुआत से मौजूद है। 2019 में git switch आने से पहले, ब्रांच बदलने के लिए git checkout का उपयोग किया जाता था। हालांकि, git checkout की परिधि सिर्फ ब्रांचों के बीच नेविगेट करने से आगे जाती है। अंतर इस प्रकार हैं:

• git switch: इसका उद्देश्य ब्रांच बदलने और नई ब्रांच बनाने का अधिक सहज तरीका देना है। यह कमांड सेट को सरल बनाता है और भ्रम कम करता है।
• git checkout: एक बहुउद्देश्यीय कमांड जो ब्रांच बदलने के साथ-साथ फाइल्स चेकआउट करने और अलग-अलग कमिट्स या ब्रांचों से कंटेंट रिस्टोर करने के लिए भी उपयोग होती है।

git switch का डिज़ाइन अनजाने में बदलावों को ओवरराइट कर देने की संभावना को कम करता है। यह ब्रांच बदलने और नई ब्रांच बनाने के लिए अधिक स्पष्ट सिन्टैक्स देता है।

क्योंकि git checkout कई काम करता है (ब्रांच बदलना, फाइलें रिस्टोर करना, आदि), इसका उपयोग करते समय गलतियाँ होने की संभावना अधिक रहती है।

Git Switch: सामान्य त्रुटियाँ

ब्रांच प्रबंधन करते समय आपको कुछ सामान्य समस्याएँ मिल सकती हैं। इनमें से एक है ऐसी ब्रांच बनाने की कोशिश करना जो लोकल में पहले से मौजूद हो। एक और आम समस्या तब होती है जब बिना कमिट किए गए बदलावों के साथ ब्रांच बदलने की कोशिश की जाती है। पहले वाली स्थिति को समझते हैं।

ब्रांच लोकल में पहले से मौजूद है

हर लोकल ब्रांच का एक यूनिक नाम होना चाहिए। आप git switch से दो तरीकों से लोकल ब्रांच बना सकते हैं:

1. किसी रिमोट ब्रांच को ट्रैक करने के लिए:

git switch --track origin/<branch-name>संचालित द्वारा

2. नई लोकल ब्रांच बनाने के लिए:

git switch -c <branch-name>संचालित द्वारा

दोनों ही स्थितियों में, यदि <branch-name> नाम की लोकल ब्रांच पहले से मौजूद है, तो Git यह त्रुटि देगा:

fatal: a branch named '<branch-name>' already existsसंचालित द्वारा

इस स्थिति में, हम git switch <branch-name> का उपयोग करके उसे बनाए बिना ही उस ब्रांच पर स्विच कर सकते हैं।

वर्तमान ब्रांच में बिना कमिट किए बदलाव हैं

यदि वर्तमान ब्रांच में ऐसे अनकमीटेड बदलाव हैं जो स्विच करने पर ओवरराइट हो जाएंगे, तो Git हमें ब्रांच बदलने नहीं देगा। इस स्थिति में Git यह त्रुटि देगा:

Please commit your changes or stash them before you switch branches.संचालित द्वारा

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

git commit -m "Commit message"संचालित द्वारा

यदि हम बदलावों को रखना चाहते हैं लेकिन अभी कमिट करने के लिए तैयार नहीं हैं, तो हम उन्हें अस्थायी रूप से git stash कमांड से सहेज सकते हैं:

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

यदि हमने ब्रांच बदलने से पहले बदलावों को स्टैश किया है और मूल ब्रांच पर लौटते समय उन्हें फिर से लागू करना चाहते हैं, तो हम git stash pop कमांड का उपयोग कर सकते हैं।

वैकल्पिक रूप से, हम --discard-changes फ्लैग का उपयोग करके बदलावों को त्यागने का भी निर्णय ले सकते हैं:

git switch --discard-changes <branch-name>संचालित द्वारा

दूसरे विकल्प का उपयोग करने से पहले सावधान रहें क्योंकि बदलाव स्थायी रूप से हट जाएंगे।

Git Switch: उन्नत उपयोग

जब आपको अपने प्रोजेक्ट के इतिहास के किसी विशिष्ट बिंदु से ब्रांच बनानी हो या विशेष परिस्थितियों को संभालना हो, तो git switch इसके लिए उन्नत क्षमताएँ प्रदान करता है।

किसी विशिष्ट बिंदु से ब्रांचिंग

डिफ़ॉल्ट रूप से, git switch से ब्रांच बनाते समय नई ब्रांच की प्रारंभिक स्थिति उस ब्रांच के HEAD से होगी जिस पर हम वर्तमान में हैं।

मान लीजिए हम किसी पूर्व के विशिष्ट कमिट से नई ब्रांच शुरू करना चाहते हैं। हर कमिट एक यूनिक <hash> से पहचाना जाता है, जिसे हम उस कमिट से नई ब्रांच बनाने के लिए git switch कमांड के साथ उपयोग कर सकते हैं। ऐसा करने का तरीका यह है:

switch -c feature-y <hash>संचालित द्वारा

<hash> को वास्तविक कमिट हैश से बदलें।

Detached HEAD पर स्विच करना

यदि हम किसी विशेष कमिट को वर्तमान ब्रांच को प्रभावित किए बिना या नई ब्रांच बनाए बिना खोजबीन या प्रयोग करना चाहते हैं, तो हम इस कमांड के साथ detached head का उपयोग कर सकते हैं:

git switch --detach <hash>संचालित द्वारा

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

• पुरानी स्थिति देखना: यदि हम किसी पुराने कमिट का निरीक्षण या परीक्षण करना चाहते हैं, बिना वर्तमान ब्रांच में बदलाव किए, तो हम उस कमिट पर detached स्थिति में स्विच कर सकते हैं।
• अस्थायी बदलाव: यदि हम किसी भी ब्रांच को प्रभावित किए बिना बदलावों के साथ प्रयोग करना चाहते हैं, तो हम detached head अवस्था में वे बदलाव कर सकते हैं। ध्यान दें कि इस अवस्था में किए गए किसी भी नए कमिट का कोई ब्रांच से संबंध नहीं होगा, और यदि हम उन कमिट्स को रखना चाहते हैं तो हमें नई ब्रांच बनानी पड़ सकती है।
• बिल्ड/टेस्ट उद्देश्यों के लिए: कभी-कभी हमें किसी विशिष्ट कमिट पर सॉफ़्टवेयर को बिल्ड या टेस्ट करना होता है। उस कमिट पर detached HEAD अवस्था में स्विच करने से हम ऐसा रिपॉजिटरी की ब्रांच संरचना पर प्रभाव डाले बिना कर सकते हैं।

स्विच को फोर्स करना

हमने सीखा कि यदि अनकमीटेड बदलाव हैं जो लक्ष्य ब्रांच से टकरा सकते हैं, तो Git हमें ब्रांच स्विच नहीं करने देगा। यदि हम निश्चित हैं कि हमें वे बदलाव त्यागकर आगे बढ़ना है, तो हम -f विकल्प का उपयोग करके इसे फोर्स कर सकते हैं, इस तरह:

git switch -f <branch-name>संचालित द्वारा

कुछ महत्वपूर्ण सावधानियाँ ध्यान देने योग्य हैं. 

• किसी भी अनकमीटेड बदलाव को बिना चेतावनी के खो दिया जाएगा, और यदि वे बदलाव कहीं और सहेजे नहीं गए हैं तो काम के नुकसान की आशंका है। 
• बिना सोच-विचार के -f का उपयोग अनुशासन की कमी को बढ़ावा दे सकता है, जिससे डेवलपर्स स्टैशिंग या काम-चल-रहा (WIP) बदलावों को कमिट करने जैसी उचित वर्ज़न कंट्रोल प्रथाओं को दरकिनार कर देते हैं। इससे रिपॉजिटरी का इतिहास अव्यवस्थित हो सकता है और सहयोग जटिल हो सकता है। इसलिए, भले ही git switch -f गति और आसानी प्रदान करता है, इसे समझदारी से और जोखिमों को स्पष्ट रूप से समझकर ही उपयोग करना चाहिए ताकि संभावित खामियों को कम किया जा सके।

निष्कर्ष

git switch कमांड, पुराने git checkout की तुलना में ब्रांच बदलना और बनाना आसान बनाता है।

यह प्रक्रिया को सरल करता है और गलतियों की संभावना कम करता है, जिससे डेवलपर्स के लिए अपने कोडबेस को प्रबंधित करना आसान हो जाता है।

यह कमांड आम समस्याओं से बचने में मदद करता है, जैसे गलती से बदलावों को ओवरराइट कर देना या git checkout के अलग-अलग कार्यों में भ्रम होना।

इस कमांड को अपनाने से Git ब्रांचों में नेविगेशन अधिक सहज हो सकता है और विकास टीमों के भीतर सहयोग बेहतर हो सकता है।