Git Stash Pop: ब्रांच बदलते समय काम सुरक्षित रखें

अगर आपके पास अधूरा काम है जो अभी कमिट करने लायक नहीं, लेकिन आपको तुरंत कॉन्टेक्स्ट बदलना है, तो "WIP" कमिट न करें। यह भी न करें कि बदलावों को किसी टेक्स्ट फ़ाइल में कॉपी-पेस्ट कर दें जैसे 2005 हो। git stash ही काफी है।

यह कमांड कॉन्टेक्स्ट बदलते समय बिना कमिट किए हुए काम को सुरक्षित रखने का बेहतरीन तरीका है। यह बदलावों को अस्थायी रूप से स्टोर करने देता है, दूसरी ब्रांचों पर जरूरी काम निपटाने देता है, और फिर सबकुछ वहीं लौटा देता है जहाँ आपने छोड़ा था।

इस लेख में, मैं बताऊंगा कि git stash pop कैसे काम करता है, इसे git stash apply पर कब प्राथमिकता दें, और कॉन्टेक्स्ट में टकराव (conflicts) आने पर रिकवरी कैसे करें।

अगर आप Git में नए हैं और स्टैशिंग की अवधारणा उलझनभरी लगती है, तो पहले बुनियादी बातें सीख लें। हमारे Introduction to Git और Introduction to GitHub कोर्स आपको जल्दी गति में ले आएंगे।

Git Stash को समझना

Git stash बिना कमिट किए गए बदलावों के लिए आपका अस्थायी स्टोरेज है।

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

कमांड आपके मॉडिफिकेशंस को सेव करता है और वर्किंग डायरेक्टरी को HEAD कमिट से मैच करा देता है।

Git में स्टैशिंग का विचार

स्टैशिंग एक सीधी समस्या हल करता है: Git आपको बिना कमिट किए बदलावों के साथ ब्रांच बदलने नहीं देता।

मान लें आप एक फीचर पर काम कर रहे हैं और एक बग रिपोर्ट आती है। आपको तुरंत दूसरी ब्रांच पर जाना है, लेकिन आपका कोड आधा लिखा है और फाइलें बदली हुई हैं। कमिट समझ में नहीं आता क्योंकि काम अधूरा है। फोर्स्ड चेकआउट से बदलाव खो जाएंगे।

यहीं आप स्टैश करते हैं।

ये सबसे आम परिदृश्य हैं जहाँ स्टैशिंग मदद करती है:

1. तुरंत काम के लिए ब्रांच बदलना: आप फीचर के बीच में हैं और प्रोडक्शन बग ठीक करना है।
2. रिमोट बदलाव पुल करना: आपके साथी ने अपडेट पुश किए हैं और आपको पुल करना है, लेकिन आपके पास लोकल मॉडिफिकेशंस हैं।
3. गंदे कमिट्स से बचना: आप कमिट के लिए तैयार नहीं हैं, लेकिन रीबेसिंग या मर्जिंग के लिए क्लीन वर्किंग डायरेक्टरी चाहिए।
4. प्रायोगिक कोड सहेजना: आप अलग तरीका आज़माना चाहते हैं बिना मौजूदा काम खोए

स्टैशिंग तेज़ और रिवर्सिबल है - कमिट मैसेज या ब्रांच नामों पर सोचने की जरूरत नहीं।

स्टैश स्टैक आर्किटेक्चर

Git स्टैशेज़ को लास्ट-इन, फ़र्स्ट-आउट (LIFO) स्टैक में रखता है।

हर बार जब आप स्टैश करते हैं, Git स्टैक के शीर्ष पर नई एंट्री बनाता है। सबसे नया स्टैश stash@{0} बनता है, और पुराने नीचे शिफ्ट होते हैं: stash@{1}, stash@{2}, आदि।

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

1. आपकी वर्किंग डायरेक्टरी के बदलाव
2. आपके स्टेज्ड बदलाव (इंडेक्स)
3. अनट्रैक्ड फाइलें (यदि आपने u फ़्लैग का उपयोग किया)

इस स्ट्रक्चर का मतलब है कि स्टैश सिर्फ स्नैपशॉट नहीं हैं। वे पूरे कमिट्स हैं जिन्हें Git बाद में आपकी वर्किंग डायरेक्टरी में मर्ज कर सकता है।

आप स्टैश को दो तरीकों से संदर्भित कर सकते हैं - इंडेक्स से stash@{0} सिंटैक्स का उपयोग करके, या git stash list से मैसेज देखकर और उसी विशेष स्टैश को संदर्भित करके। हाल के स्टैश के लिए इंडेक्स तेज़ है, लेकिन जब आपके पास कई स्टैश हों तो मैसेज बेहतर होते हैं।

एक सामान्य स्टैश स्टैक कुछ ऐसा दिखता है:

WIP on प्रिफिक्स का मतलब है कि आपने git stash बिना मैसेज के चलाया। On प्रिफिक्स का मतलब है कि आपने git stash push -m के साथ कस्टम मैसेज दिया।

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

स्टैश बनाना, मैनेज करना, और जाँचना

बेसिक git stash कमांड शुरुआत के लिए काफी है, लेकिन यह आलसी तरीका है। अंत में आपके पास "WIP on branch-name" एंट्रीज़ का ढेर हो जाएगा जो अंदर क्या है, इसके बारे में कुछ नहीं बतातीं। छह हफ्ते बाद, आपको याद नहीं रहेगा कि कौन सा स्टैश बग फिक्स रखता है और कौन सा अधूरा रिफैक्टर।

अब मैं शुरू से ही सही तरीका दिखाऊंगा।

उपयुक्त मेटाडेटा के साथ स्टैश बनाना

स्टैश करने का सबसे सरल तरीका बस git stash टाइप करना है:

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

यह आपके बदलाव सेव कर देता है, लेकिन "WIP on main" संदेश ज़्यादा जानकारीपूर्ण नहीं है। बिना जाँचे आप नहीं बता सकते कि अंदर क्या है।

इसके बजाय, git stash push -m को एक वर्णनात्मक संदेश के साथ चलाएँ:

git stash push -m "Updated file.txt"संचालित द्वारा

अब आपका स्टैश लिस्ट वाकई जानकारी देता है:

फ़र्क साफ है। एक एंट्री आपको बताती है आपने क्या किया, जबकि दूसरी आपको अंदाज़ा लगाने पर मजबूर करती है।

मैसेज ऐसे लिखें जैसे आप अपने भविष्य के लिए नोट छोड़ रहे हों। "ऑथ लॉजिक जोड़ें," "नेवबार बग ठीक करें," या "नए API डिज़ाइन के साथ प्रयोग" हर बार जनरल WIP संदेशों से बेहतर हैं।

अनट्रैक्ड या इग्नोर्ड फाइलें शामिल करना

डिफ़ॉल्ट रूप से, git stash सिर्फ ट्रैक्ड फाइलें सेव करता है - यानी वे फाइलें जिन्हें Git पहले से जानता है।

अनट्रैक्ड फाइलें आपकी वर्किंग डायरेक्टरी में रहती हैं। यह अक्सर लोगों को चौंका देता है जब वे स्टैश करते हैं, ब्रांच बदलते हैं, और नई फाइलें वहीं दिखती हैं।

यहाँ क्या होता है:

echo "new_feature.py" > new_feature.py
git stashसंचालित द्वारा

फ़ाइल स्टैश नहीं हुई क्योंकि Git अभी उसे ट्रैक नहीं कर रहा:

इसे दरकिनार करने के लिए, अनट्रैक्ड फाइलें स्टैश करने हेतु -u फ़्लैग का उपयोग करें:

git stash push -u -m "Added a Python file for a new cool feature"संचालित द्वारा

यह ट्रैक्ड और अनट्रैक्ड दोनों फाइलें स्टैश करता है। आपकी वर्किंग डायरेक्टरी पूरी तरह साफ हो जाती है।

टिप: आप -a फ़्लैग जोड़कर इग्नोर्ड फाइलें भी शामिल कर सकते हैं। यह ट्रैक्ड फाइलें, अनट्रैक्ड फाइलें, और आपकी .gitignore में शामिल फाइलें स्टैश करता है। इसकी जरूरत कम ही पड़ती है, जब तक कि आप बिल्ड इश्यू डिबग न कर रहे हों या सबकुछ का पूरी तरह साफ स्नैपशॉट न चाहिए।

यहाँ एक चीट शीट है ताकि आपको पता हो कि किस फ़्लैग का इस्तेमाल कब करें:

1. कोई फ़्लैग नहीं: आपने सिर्फ मौजूदा फाइलें बदली हैं

2. u फ़्लैग: आपने नई फाइलें जोड़ी हैं जिन्हें अभी ट्रैक नहीं किया गया

3. a फ़्लैग: आपको सबकुछ सेव करना है, बिल्ड आउटपुट या टेम्प फाइलों सहित

अधिकतर समय, आप -u का उपयोग करेंगे। डेवलपमेंट के दौरान नई फाइलें बनी हों तो यह सबसे सुरक्षित विकल्प है।

आंशिक या चयनात्मक स्टैशिंग

आपको वर्किंग डायरेक्टरी की हर चीज़ स्टैश करने की आवश्यकता नहीं।

मान लें आपने दो बग ठीक किए, लेकिन आप सिर्फ एक को स्टैश करना चाहते हैं। या पाँच फाइलों में बदलाव हैं, लेकिन फीचर से संबंधित सिर्फ तीन को सेव करना चाहते हैं।

आप पाथस्पेक के साथ विशिष्ट फाइलें स्टैश कर सकते हैं:

git stash push -m "New files" new_file.txt new_file_2.txtसंचालित द्वारा

यह केवल new_file.txt और new_file_2.txt को स्टैश करेगा। बाकी सब आपकी वर्किंग डायरेक्टरी में रहेगा।

आप वाइल्डकार्ड भी इस्तेमाल कर सकते हैं:

git stash push -m "Stash all txt files" *.txtसंचालित द्वारा

या, आप इंटरैक्टिव स्टैशिंग के लिए --patch का उपयोग कर सकते हैं:

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

Git हर बदलाव से गुज़रता है और पूछता है कि आप उसे स्टैश करना चाहते हैं या नहीं। आप y (हाँ), n (नहीं), या s (हंक को छोटे हिस्सों में बाँटें) से जवाब देते हैं।

जब एक ही फ़ाइल में संबंधित और असंबंधित बदलाव मिश्रित हों, तब यह काम आता है। फीचर का काम स्टैश करें और डीबग कोड पीछे छोड़ दें।

इंटरैक्टिव प्रॉम्प्ट कुछ ऐसा दिखता है:

स्टैश लिस्ट करना और जाँचना

जैसा आपने देखा, आप git stash list चलाकर सभी स्टैश देख सकते हैं:

सबसे नया स्टैश हमेशा stash@{0} होता है। पुराने स्टैश इंडेक्स में नीचे शिफ्ट होते हैं।

यदि आपने अच्छे मैसेज लिखे हैं, तो आप इस सूची को स्कैन करके प्रत्येक स्टैश में क्या है जान सकते हैं। अगर नहीं, तो आपको उन्हें एक-एक करके जाँचना होगा।

सारांश देखने के लिए git stash show का उपयोग करें:

यह दिखाता है कि कौन सी फाइलें बदलीं और कितनी पंक्तियाँ जोड़ीं या हटाईं गईं।

वैकल्पिक रूप से, पूरा डिफ देखने के लिए git stash show -p का उपयोग करें:

यहाँ -p फ़्लैग असल कोड बदलाव दिखाता है, ठीक git diff की तरह। इससे आप git stash pop चलाने से पहले सही स्टैश की पुष्टि कर सकते हैं।

Git Stash Pop वास्तव में क्या करता है

अब बात करते हैं कि git stash pop वास्तव में क्या करता है और आप इसे क्यों इस्तेमाल करेंगे।

मौलिक व्यवहार और सिंटैक्स

git stash pop दो काम करता है: यह आपके स्टैश किए बदलाव अप्लाई करता है और फिर उस स्टैश को स्टैक से हटा देता है।

बेसिक सिंटैक्स यह है:

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

यह सबसे हालिया स्टैश (stash@{0}) को पॉप करता है और उसे आपकी स्टैश लिस्ट से हटा देता है।

आप इंडेक्स रेफरेंस करके किसी विशेष स्टैश को भी पॉप कर सकते हैं:

git stash pop stash@{1}संचालित द्वारा

यह stash@{1} को अप्लाई और रिमूव करता है, लेकिन एक बात - बाकी स्टैश ऊपर शिफ्ट हो जाते हैं। जो stash@{2} था, वो stash@{1} बन जाता है, आदि।

Git स्टैश पॉप को कैसे प्रोसेस करता है

जब आप git stash pop चलाते हैं, Git पर्दे के पीछे थ्री-वे मर्ज करता है।

यह तीन अवस्थाओं की तुलना करता है:

1. बेस कमिट (जहाँ आपने स्टैश बनाया)
2. आपका वर्तमान HEAD कमिट
3. स्टैश किए गए बदलाव

यदि मर्ज बिना कॉन्ट्फ्लिक्ट के सफल हो जाता है, तो Git आपके बदलाव अप्लाई करता है और स्टैश हटा देता है। आपकी वर्किंग डायरेक्टरी बिल्कुल वैसी दिखती है जैसी स्टैश करने से पहले थी।

एक सरल वर्कफ़्लो उदाहरण:

# You're working on a feature
echo "new feature code" >> feature.py
git stash push -m "Half-finished feature work"

# Switch to new branch and make unrelated changes
git checkout bugfix
echo "bug fix" >> bugfix.py
git add bugfix.py
git commit -m "Fix critical bug"

# Go back to your other branch
git checkout main

# Pop your stashed work
git stash popसंचालित द्वारा

यदि Git क्लीन मर्ज नहीं कर पाता, तो कॉन्ट्फ्लिक्ट आते हैं। पॉप सफलतापूर्वक पूरा नहीं हुआ हो तो स्टैश स्टैक में बना रहता है। आपको फाइलों में कॉन्ट्फ्लिक्ट मार्कर दिखेंगे, जैसे सामान्य मर्ज कॉन्ट्फ्लिक्ट में।

कॉन्ट्फ्लिक्ट आने पर, आपको उन्हें मैन्युअली सुलझाना होगा, फिक्स्ड फाइलें स्टेज करनी होंगी, और कमिट करना होगा। स्टैश अपने-आप नहीं हटेगा, इसलिए सबकुछ सुलझाने के बाद आपको git stash drop चलाना होगा।

ब्रांचों के बीच स्टैश अप्लाई करना

स्टैश किसी विशेष ब्रांच से बंधे नहीं होते।

आप bugfix पर स्टैश बना सकते हैं, main पर स्विच कर सकते हैं, और वहाँ उसे पॉप कर सकते हैं। Git को फर्क नहीं पड़ता स्टैश कहाँ से आया - वह बस मौजूदा ब्रांच पर बदलाव अप्लाई करने की कोशिश करता है।

इससे कुछ उपयोगी वर्कफ़्लो खुलते हैं:

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

2. टास्क्स का पुनर्गठन: आपने एक हफ्ता पहले कुछ प्रायोगिक कोड स्टैश किया था। अब आप उसे दूसरी ब्रांच पर आज़माना चाहते हैं कि शायद वहाँ बेहतर काम करे।

3. अलग कॉन्टेक्स्ट में बदलाव टेस्ट करना: आपके पास बग फिक्स स्टैश है, और आप कमिट करने से पहले उसे कई ब्रांचों पर टेस्ट करना चाहते हैं। स्टैश को बनाए रखने के लिए git stash apply का उपयोग करें, अलग-अलग ब्रांचों पर टेस्ट करें, फिर जिस ब्रांच पर कमिट करना हो वहाँ pop करें। apply पर आगे बात करेंगे।

जब तक बदलाव आपकी मौजूदा ब्रांच से कॉन्ट्फ्लिक्ट नहीं करते, स्टैश साफ़-सुथरे तरीके से अप्लाई हो जाएगा - यही मुख्य बात याद रखें।

Git Stash Pop बनाम Git Stash Apply

डेवलपर्स अक्सर सोचते हैं कि git stash pop या git stash apply में से क्या उपयोग करें।

मुख्य अंतर: स्टैश का बना रहना

मुख्य फर्क सरल है: pop अप्लाई करने के बाद स्टैश हटा देता है, जबकि apply उसे स्टैक में बनाए रखता है।

pop के साथ, आप कहते हैं "मैं इस स्टैश से हो चुका - इसे अप्लाई करो और हटा दो।" apply के साथ, आप कहते हैं "मुझे यह बाद में फिर चाहिए हो सकता है।"

इससे आपका वर्कफ़्लो दो तरह से प्रभावित होता है:

1. सुरक्षा: यदि pop के दौरान कुछ गलत हो जाए और आपको रिकवर करना पड़े, तो स्टैश जा चुका होता है। apply के साथ, स्टैश बैकअप के रूप में स्टैक में बना रहता है।

2. सफाई: pop उपयोग करने से स्टैश लिस्ट अपने-आप साफ रहती है। apply का उपयोग करने का मतलब है कि बाद में git stash drop मैन्युअली चलाकर अनचाहे स्टैश हटाने होंगे।

अधिकांश डेवलपर्स डिफ़ॉल्ट रूप से pop का उपयोग करते हैं क्योंकि यह क्लीनर है। लेकिन apply बेहतर है जब आपको यकीन न हो कि स्टैश मौजूदा ब्रांच पर साफ़-सुथरा अप्लाई होगा, या जब आप वही बदलाव कई ब्रांचों पर टेस्ट करना चाहते हों।

पूर्वानुमेयता, जोखिम, और इंडेक्स शिफ्टिंग

यहाँ pop पेचीदा होता है - जब आप स्टैक के बीच से पॉप करते हैं तो स्टैश इंडेक्स शिफ्ट होते हैं।

मान लें आपके पास तीन स्टैश हैं:

stash@{0}: Feature work
stash@{1}: Bug fix
stash@{2}: Experimental codeसंचालित द्वारा

यदि आप stash@{1} को पॉप करते हैं, तो बाकी स्टैश ऊपर शिफ्ट होते हैं:

stash@{0}: Feature work
stash@{1}: Experimental codeसंचालित द्वारा

यह तब समस्या पैदा कर सकता है जब आप Git ऑपरेशंस स्क्रिप्ट कर रहे हों या क्रम में कई पॉप कमांड चला रहे हों। आप stash@{1} पॉप करते हैं, फिर stash@{2} पॉप करने की कोशिश करते हैं, लेकिन वह इंडेक्स अब मौजूद नहीं।

यह समस्या apply कमांड में नहीं है। इंडेक्स तभी शिफ्ट होते हैं जब आप स्पष्ट रूप से git stash drop चलाते हैं। आप किसी भी क्रम में स्टैश अप्लाई कर सकते हैं बिना स्टैक के नीचे से बदलने की चिंता के।

कॉन्ट्फ्लिक्ट हैंडलिंग एक जैसी

दोनों कमांड कॉन्ट्फ्लिक्ट्स को बिल्कुल एक जैसे हैंडल करते हैं।

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

1. pop के साथ: पॉप सफल नहीं हुआ तो स्टैश स्टैक में रहता है

2. apply के साथ: स्टैश स्टैक में बना रहता है (वैसे भी रहता)

दोनों ही स्थितियों में, आपको कॉन्ट्फ्लिक्ट मैन्युअली ठीक करने हैं, git add से रिज़ॉल्व्ड फाइलें स्टेज करनी हैं, और (यदि apply इस्तेमाल किया है तो) git stash drop से स्टैश हटाना है।

कॉन्ट्फ्लिक्ट रेज़ोल्यूशन वर्कफ़्लो एक जैसा है - फ़र्क सिर्फ इतना कि सफलता पर स्टैश अपने-आप हटता या नहीं।

कब किसे चुनें

git stash pop का उपयोग करें जब:

1. आप स्टैश को एक बार अप्लाई करके उससे काम पूरा कर रहे हैं
2. आप स्टैश लिस्ट अपने-आप साफ रखना चाहते हैं
3. आप एक ही ब्रांच पर काम कर रहे हैं और स्टैश अन्यत्र नहीं चाहिए

git stash apply का उपयोग करें जब:

1. आप एक ही बदलाव कई ब्रांचों पर टेस्ट करना चाहते हैं
2. आपको यकीन नहीं कि स्टैश क्लीनली अप्लाई होगा
3. आप Git ऑपरेशंस को स्क्रिप्ट कर रहे हैं और पूर्वानुमेय इंडेक्स चाहिए
4. आप चाहते हैं कि कुछ गलत होने पर सुरक्षा जाल रहे

स्टैश पॉप में कॉन्ट्फ्लिक्ट्स को संभालना

कॉन्ट्फ्लिक्ट तब होते हैं जब Git आपके स्टैश्ड बदलावों को क्लीनली मर्ज नहीं कर पाता। इस सेक्शन में, मैं बताऊँगा कि उनसे कैसे निपटें।

कॉन्ट्फ्लिक्ट कब और क्यों होते हैं

कॉन्ट्फ्लिक्ट उस थ्री-वे मर्ज के दौरान होते हैं जो Git स्टैश पॉप करते समय करता है।

Git आपके कोड के तीन वर्ज़न की तुलना करता है:

1. वह बेस कमिट जहाँ आपने स्टैश बनाया था
2. आपका मौजूदा HEAD कमिट
3. स्टैश किए गए बदलाव

अगर वही पंक्तियाँ मौजूदा ब्रांच और स्टैश - दोनों में बदली हों, तो Git नहीं जानता किसे रखें। यही कॉन्ट्फ्लिक्ट है।

स्टैश पॉप कॉन्ट्फ्लिक्ट के आम कारण:

1. आपने दोनों ब्रांचों पर एक ही फाइल बदली: आपने किसी फाइल में बदलाव स्टैश किए, ब्रांच बदली, फिर पॉप करने से पहले वही फाइल फिर एडिट की
2. किसी और ने बदलाव पुश किए: आपने काम स्टैश किया, रिमोट से अपडेट पुल किए, और उन अपडेट्स ने उसी कोड को छुआ
3. आपने रीबेस या चेरी-पिक किया: Git जिस बेस कमिट की उम्मीद करता था, वह अब मौजूद नहीं, जिससे मर्ज मिसमैच होते हैं

कुल मिलाकर, जितना ज्यादा स्टैश पड़ा रहता है, उतनी संभावना है कि पॉप करते समय कॉन्ट्फ्लिक्ट आएँ।

कॉन्ट्फ्लिक्ट रेज़ोल्यूशन वर्कफ़्लो

कॉन्ट्फ्लिक्ट होने पर, Git पॉप को रोक देता है और आपकी फाइलों में कॉन्ट्फ्लिक्ट मार्क करता है:

अब आपकी फाइल में कॉन्ट्फ्लिक्ट मार्कर हैं:

<<<<<<< Updated upstream और ======= के बीच सबकुछ आपका वर्तमान कोड है। ======= और >>>>>>> Stashed changes के बीच का हिस्सा स्टैश से है।

इसे ठीक करने के लिए आप यह कर सकते हैं:

1. कॉन्ट्फ्लिक्टेड फाइल खोलें और तय करें कौन सा वर्ज़न रखें (या दोनों मिलाएँ)

2. कॉन्ट्फ्लिक्ट मार्कर हटाएँ (<<<<<<<, =======, >>>>>>>)

3. फिक्स्ड फाइल को git add से स्टेज करें

4. स्टैश को git stash drop से मैन्युअली हटाएँ - याद रखें, यह अपने-आप नहीं हटेगा।

वैकल्पिक रणनीतियाँ

यदि आप मौजूदा ब्रांच में कॉन्ट्फ्लिक्ट से नहीं जूझना चाहते, तो git stash branch का उपयोग करें।

यह कमांड उस कमिट से नई ब्रांच बनाता है जहाँ आपने स्टैश किया था, फिर वहाँ स्टैश अप्लाई करता है:

git stash branch temp-featureसंचालित द्वारा

Git temp-feature नाम की ब्रांच बनाता है, उसे चेकआउट करता है, और उस पर आपका स्टैश पॉप करता है। क्योंकि ब्रांच ठीक उसी कमिट से शुरू होती है जहाँ आपने स्टैश किया था, कोई कॉन्ट्फ्लिक्ट नहीं होंगे। मैं इसे अलग सेक्शन में विस्तार से कवर करूँगा।

आप git reset --merge से असफल पॉप को अबॉर्ट भी कर सकते हैं:

git stash pop

# Conflicts appear

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

यह पॉप के प्रयास को पूर्ववत करता है और आपकी वर्किंग डायरेक्टरी को पॉप से पहले की स्थिति में लौटा देता है। स्टैश स्टैक में ही रहता है।

चल रहे स्टैश ऑपरेशन को अबॉर्ट करना

यदि आपने पॉप या अप्लाई शुरू किया और पूरी तरह वापस जाना चाहते हैं, तो आपके पास विकल्प हैं।

जिन कॉन्ट्फ्लिक्ट्स को आपने अभी तक ठीक करना शुरू नहीं किया, उनके लिए यह चलाएँ:

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

यह मर्ज कैंसल करता है और आपकी वर्किंग डायरेक्टरी को साफ करता है। सबकुछ वैसा ही हो जाता है जैसा स्टैश कमांड चलाने से पहले था।

जिन कॉन्ट्फ्लिक्ट्स को आपने आंशिक रूप से ठीक किया है, उनके लिए यह कमांड चलाएँ:

git reset --hard HEADसंचालित द्वारा

यह आपकी वर्किंग डायरेक्टरी में सभी बदलाव, जिनमें किए गए फिक्स भी शामिल हैं, फेंक देता है। तब उपयोग करें जब आपने गड़बड़ कर दी हो और नई शुरुआत करनी हो।

याद रखें कि यह कमांड बिना कमिट किए काम को नष्ट कर देता है। चलाने से पहले सुनिश्चित करें कि आप सच में सबकुछ हटाना चाहते हैं।

अबॉर्ट करने के बाद, आपका स्टैश स्टैक में बना रहता है (जब तक आपने pop चलाया हो और कॉन्ट्फ्लिक्ट से पहले वह सफल हुआ हो)। आप बाद में फिर कोशिश कर सकते हैं, या साफ़-सुथरे तरीके के लिए git stash branch का प्रयोग करें।

स्टैश की सफाई

लंबे प्रोजेक्ट्स में स्टैश तेजी से बढ़ते हैं। आप बग फिक्स करने के लिए स्टैश करते हैं और फिर भूल जाते हैं। आप एक्सपेरिमेंटल स्टैश बनाते हैं जिन्हें कभी पॉप नहीं करते। छह महीने बाद, आपके पास 20 स्टैश होते हैं और आधे में क्या है, पता नहीं।

इससे वह स्टैश ढूँढना कठिन हो जाता है जिसकी वाकई जरूरत है। अंत में आपको हर एक पर git stash show -p चलाना पड़ता है यह जानने के लिए कि अंदर क्या है।

यह बड़ा समय जाया है, इसलिए अपने स्टैश नियमित रूप से साफ करते रहें।

अलग-अलग स्टैश ड्रॉप करना

किसी विशेष स्टैश को हटाने के लिए git stash drop का उपयोग करें:

git stash drop stash@{2}संचालित द्वारा

यह stash@{2} को स्टैक से डिलीट करता है। बाकी स्टैश ऊपर शिफ्ट होते हैं - जो stash@{3} था, वह stash@{2} बन जाता है।

आप इंडेक्स बताए बिना सबसे नया स्टैश भी ड्रॉप कर सकते हैं:

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

यह डिफ़ॉल्ट रूप से stash@{0} हटाता है।

Git के सालों के अनुभव में, स्टैश ड्रॉप करने के मेरे शीर्ष कारण ये हैं जब:

1. आपको अहसास हो कि अब वे बदलाव चाहिए ही नहीं
2. आपके पास डुप्लिकेट स्टैश हैं (यह उम्मीद से ज्यादा होता है)
3. स्टैश इतना पुराना है कि याद नहीं वह किसलिए था

यदि पक्का नहीं कि स्टैश ड्रॉप करना है या नहीं, तो पहले git stash show -p से जाँच लें। सावधानी बेहतर है।

पूरे स्टैश स्टैक को क्लियर करना

आप git stash clear से एक साथ सभी स्टैश डिलीट कर सकते हैं:

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

याद रखें कि यह स्थायी है। इसे पूर्ववत नहीं कर सकते या बाद में स्टैश रिकवर नहीं कर सकते।

केवल तब git stash clear उपयोग करें जब आपको बिल्कुल यकीन हो कि स्टैश्ड काम में से कुछ नहीं चाहिए।

अधिकतर समय, बेहतर है कि स्टैशेज़ को अलग-अलग ड्रॉप करें ताकि गलती से कुछ ज़रूरी डिलीट न हो जाए।

स्टैश से ब्रांच बनाना

कभी-कभी सबसे साफ़ समाधान है स्टैश को अपनी अलग ब्रांच बनाना। इससे मर्ज कॉन्ट्फ्लिक्ट्स से बचाव होता है और आपके स्टैश्ड काम को सही ठिकाना मिलता है।

git stash branch का उपयोग

git stash branch कमांड एक नई ब्रांच बनाता है और उस पर आपका स्टैश अप्लाई करता है:

इसमें यह होता है:

1. Git उस कमिट से feature-experiment नाम की नई ब्रांच बनाता है जहाँ आपने स्टैश किया था

2. Git उस नई ब्रांच को चेकआउट करता है

3. Git स्टैश को ब्रांच पर पॉप करता है

4. Git आपके स्टैक से स्टैश हटा देता है (ठीक pop की तरह)

क्योंकि ब्रांच ठीक उसी कमिट से शुरू होती है जैसा स्टैश, कोई कॉन्ट्फ्लिक्ट नहीं होगा। बदलाव हर बार साफ़-सुथरे तरीके से अप्लाई होंगे।

आप सबसे नए के बजाय किसी विशिष्ट स्टैश का भी उपयोग कर सकते हैं:

git stash branch new-feature stash@{2}संचालित द्वारा

सामान्य उपयोग के मामले

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

आपको प्रयोग पर काम करने के लिए एक क्लीन ब्रांच मिलती है। अगर सफल रहा, तो मर्ज कर दें। नहीं तो ब्रांच डिलीट करके आगे बढ़ें।

यह लंबे रीबेस के लिए भी बढ़िया है। रीबेस के दौरान संभावित कॉन्ट्फ्लिक्ट झेलने के बजाय, सबकुछ स्टैश करें और उससे ब्रांच बना लें।

git stash push -m "WIP before rebase"
git rebase main
git stash branch temp-workसंचालित द्वारा

अब आप स्टैश किए बदलावों को अलग से रिव्यू कर सकते हैं और रीबेस के बाद कैसे इंटीग्रेट करना है, तय कर सकते हैं।

बड़ी या उलझी हुई चेंजसेट को अलग करने के लिए ब्रांच बनाना भी उपयोगी है। सोचें आपके पास 15 फाइलों में बदलावों वाला बड़ा स्टैश है, जिनमें से आधे मौजूदा ब्रांच से कॉन्ट्फ्लिक्ट करते हैं। बस नई ब्रांच बना लें - रास्ता साफ़।

आपको एक डेडिकेटेड ब्रांच मिलती है जहाँ आप शांति से सबकुछ रिव्यू कर सकते हैं, ढंग से कमिट कर सकते हैं, और फिर साफ़ हिस्ट्री के साथ मर्ज कर सकते हैं।

एडवांस्ड तकनीकें और रिकवरी विकल्प

अब तक आप git stash की बुनियाद से परिचित हैं, तो अब कुछ उन्नत अवधारणाएँ देखते हैं।

विशिष्ट स्टैश एंट्रीज़ के साथ काम करना

आप स्टैक में किसी भी स्टैश को पॉप या अप्लाई कर सकते हैं, सिर्फ सबसे नए को ही नहीं।

ज़रूरत के मुताबिक स्टैश को उसकी इंडेक्स से संदर्भित करें:

git stash pop stash@{3}
git stash apply stash@{1}संचालित द्वारा

इससे आप पुराने स्टैशेज़ ले सकते हैं बिना नए छुए। जब आप बीच का स्टैश पॉप करते हैं, तो नीचे के सभी इंडेक्स ऊपर शिफ्ट होते हैं। जो stash@{4} था, वह stash@{3} बन जाता है, आदि। यदि आप Git ऑपरेशंस स्क्रिप्ट कर रहे हैं या क्रम में कई स्टैश पॉप कर रहे हैं, तो यह इंडेक्स शिफ्टिंग आपके कमांड तोड़ देगी।

समाधान है जब पूर्वानुमेय इंडेक्स चाहिए तो pop की जगह apply का उपयोग करना:

git stash apply stash@{2}

# काम होने पर मैन्युअली ड्रॉप करें
git stash drop stash@{2}संचालित द्वारा

इससे आपके पास स्टैक कब बदले, इस पर पूरा नियंत्रण रहता है। आप स्टैश अप्लाई करें, सत्यापित करें कि सही काम हुआ है, फिर खुद ड्रॉप करें। इंडेक्स तभी शिफ्ट होते हैं जब आप स्पष्ट रूप से ऐसा करें।

स्टेज्ड स्टेट बहाल करना

डिफ़ॉल्ट रूप से, git stash pop और git stash apply आपके बदलाव तो लौटाते हैं पर स्टेज्ड क्या था, यह संरक्षित नहीं रहता।

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

समाधान है --index फ़्लैग का उपयोग, ताकि स्टेजिंग स्टेट ठीक वैसा ही बहाल हो:

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

यह आपके स्टैश से पहले की वर्किंग ट्री और इंडेक्स को हूबहू रिक्रिएट करता है। जो फाइलें स्टेज्ड थीं, वे स्टेज्ड ही रहती हैं। जो अनस्टेज्ड थीं, वे अनस्टेज्ड ही रहती हैं। सबकुछ बिल्कुल पहले जैसा।

आपको इस फ़्लैग की जरूरत तब होगी जब:

1. आप सावधानी से तैयार किए गए स्टेज्ड कमिट के बीच में हों और वह जानकारी खो नहीं सकते

2. आप कॉम्प्लेक्स स्टेजिंग परिदृश्य में हों, जैसे आपने git add -p से केवल विशिष्ट हंक्स स्टेज किए हों

3. आप चाहते हैं कि वर्किंग डायरेक्टरी बिल्कुल स्टैश से पहले जैसी दिखे, बिना किसी अपवाद के

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

स्टैश से हुई गलतियों से उबरना

कभी-न-कभी आप कोई ज़रूरी स्टैश ड्रॉप कर देंगे या गलती से पूरा स्टैक क्लियर कर देंगे।

ऐसा हो तो git का रिफ़लॉग आपका दिन बचा सकता है।

रिफ़लॉग आपकी रिपॉज़िटरी में हर रेफरेंस बदलाव ट्रैक करता है, स्टैश सहित। जब आप स्टैश बनाते या ड्रॉप करते हैं, Git उसे रिफ़लॉग में रिकॉर्ड करता है। स्टैश ड्रॉप करने के बाद भी, कुछ समय तक कमिट्स अनरीचेबल ऑब्जेक्ट्स के रूप में मौजूद रहते हैं।

आप अनरीचेबल कमिट्स खोजकर खोया स्टैश ढूँढ सकते हैं:

git fsck --unreachable | grep commitसंचालित द्वारा

अब आप हर कमिट चेक कर सकते हैं अपना स्टैश ढूँढने के लिए:

git show 066ded985342e585bc8e75c074add99ec1950f50संचालित द्वारा

डिफ और कमिट मैसेज देखें ताकि पता चले कौन सा आपका खोया स्टैश है। सही कमिट मिलते ही उसे रिकवर करें:

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

यह खोए हुए स्टैश को आपकी वर्किंग डायरेक्टरी में ऐसे अप्लाई कर देता है जैसे वह कभी ड्रॉप हुआ ही नहीं।

और बेहतर, शुरू में ही गलतियाँ रोकें इन बेहतरीन प्रथाओं से:

1. वर्णनात्मक स्टैश मैसेज लिखें ताकि आप ठीक-ठीक जानें क्या ड्रॉप कर रहे हैं। पाँच स्टैश की लिस्ट देखते समय "Fix login bug" "WIP" से बेहतर है।

2. git stash show -p ड्रॉप करने से पहले चलाएँ ताकि पुष्टि हो कि सही स्टैश है। पाँच सेकंड की पुष्टि पाँच मिनट की रिकवरी से बेहतर है।

3. अपने स्टैश स्टैक को नियमित रूप से साफ रखें ताकि वह बिखरे नहीं। तीन प्रासंगिक स्टैश वाला स्टैक 15 पुराने एंट्रीज़ वाले से आसान है।

4. जब आपको 100% यकीन न हो कि स्टैश डिलीट करना है, तब pop की बजाय apply का उपयोग करें। सबकुछ वेरिफाई होने के बाद आप हमेशा ड्रॉप कर सकते हैं।

रिफ़लॉग रिकवरी काम करती है, लेकिन थकाऊ है। ऊपर की छवि देखें कि मुझे कितने कमिट्स मैन्युअली चेक करने पड़ेंगे - और यह तो सिर्फ इस लेख के लिए बनाया गया छोटा प्रोजेक्ट है।

उत्तम प्रथाएँ और वर्कफ़्लो गाइडलाइंस

स्टैश का अच्छा उपयोग करने का मतलब है ऐसे पैटर्न फॉलो करना जो गलतियों को रोकें और वर्कफ़्लो को साफ रखें। मैं अपना पसंदीदा तरीका बताता हूँ।

अनुशंसित वर्कफ़्लो पैटर्न

सबसे सुरक्षित स्टैश वर्कफ़्लो एक सरल पैटर्न का अनुसरण करता है: मैसेज के साथ स्टैश करें, कॉन्टेक्स्ट बदलें, फिर तैयार होने पर पॉप करें।

# Work on feature-branch
git stash push -m "Feature work in progress"

git checkout main
# Do urgent work on main

# Go back
git checkout feature-branch
git stash popसंचालित द्वारा

यह अधिकांश स्थितियों में काम करता है। आप अपना काम सुरक्षित रखते हैं, बाधा सँभालते हैं, और सबकुछ साफ़-सुथरे तरीके से बहाल करते हैं।

एक और सामान्य पैटर्न है "पॉप से पहले निरीक्षण"। आप स्टैश लिस्ट करते हैं, अंदर क्या है देखते हैं, फिर सही वाले को पॉप करते हैं।

git stash list
git stash show -p stash@{1}
git stash pop stash@{1}संचालित द्वारा

यह अतिरिक्त वेरिफिकेशन स्टेप आपको गलत स्टैश पॉप करने या पुराना काम अप्लाई करने से बचाता है।

कुछ डेवलपर्स स्टैशिंग के विकल्प के रूप में "अनिच्छुक कमिट" पसंद करते हैं। स्टैश करने के बजाय, वे "WIP - not ready" जैसा मैसेज देकर टेम्परेरी कमिट बनाते हैं और बाद में उसे अमेंड या रीसेट करते हैं। यह तब ठीक है जब आप स्टैश से असहज हों या काम को ब्रांच हिस्ट्री में ट्रैक करना चाहें। नुकसान यह कि अगर साफ़ करना भूल जाएँ तो कमिट लॉग गंदे हो जाते हैं।

डेवलपमेंट टूल्स के साथ इंटीग्रेशन

ज्यादातर Git GUI आपके स्टैश को विजुअली दिखाते हैं और एक क्लिक में पॉप या अप्लाई करने देते हैं।

GitKraken, Sourcetree, और GitHub Desktop जैसे टूल्स साइडबार में स्टैश लिस्ट करते हैं। आप मैसेज देख सकते हैं, डिफ निरीक्षण कर सकते हैं, और बिना कमांड टाइप किए स्टैश अप्लाई या ड्रॉप कर सकते हैं। यह तब काम आता है जब आपके पास कई स्टैश हों और आप उन्हें साथ-साथ तुलना करना चाहें।

VS Code का Git एक्सटेंशन सोर्स कंट्रोल पैनल में स्टैश दिखाता है। आप राइट-क्लिक करके एडिटर छोड़े बिना पॉप, अप्लाई, या ड्रॉप कर सकते हैं।

अगर आप कमांड लाइन पसंद करते हैं, तो शेल एलियास स्टैशिंग तेज़ बनाते हैं। इन्हें अपनी .bashrc या .zshrc में जोड़ें:

alias gst='git stash'
alias gstp='git stash pop'
alias gstl='git stash list'
alias gsts='git stash show -p'संचालित द्वारा

अब gst आपका काम स्टैश करेगा, gstp उसे पॉप करेगा, gstl स्टैश लिस्ट दिखाएगा, और gsts डिफ दिखाएगा। हर बार कुछ कीस्ट्रोक्स बचेंगे।

स्टैश हाइजीन और टीम संबंधी बातें

स्टैश आपकी मशीन पर लोकल होते हैं - वे कभी रिमोट रिपॉज़िटरी पर पुश नहीं होते।

इसका मतलब आपकी टीम आपके स्टैश नहीं देख सकती, और आप दूसरी मशीन से उन्हें एक्सेस नहीं कर सकते। अगर आपको वर्क-इन-प्रोग्रेस साझा करना है, तो उसे स्टैश न करें। पैचेस या टेम्परेरी ब्रांच का उपयोग करें।

पैच के ज़रिए काम साझा करने के लिए, यह चलाएँ:

git stash show -p > my-work.patch
# Send the patch file to your teammate
# They apply it with: git apply my-work.patchसंचालित द्वारा

अब पैच फ़ाइल अपने साथी को भेजें, और वे git apply my-work.patch चलाकर उसे अप्लाई कर लेंगे।

टेम्परेरी ब्रांच के ज़रिए काम साझा करने के लिए, यह चलाएँ:

git checkout -b temp/work-in-progress
git add .
git commit -m "WIP - authentication feature"
git push origin temp/work-in-progressसंचालित द्वारा

आपका साथी ब्रांच पुल कर सकता है, काम की समीक्षा कर सकता है, और वहीं से आगे बढ़ सकता है।

जो भी तरीका चुनें, हमेशा अच्छी स्टैश हाइजीन बनाए रखें। इससे भ्रम नहीं होगा और आपका लोकल स्टैक मैनेजेबल रहेगा। ये कुछ अच्छी प्रथाएँ हैं:

1. हर स्टैश के लिए वर्णनात्मक नामों का उपयोग करें। "Add user auth logic" बताता है अंदर क्या है। "WIP on feature-branch" कुछ नहीं बताता।

2. सप्ताह में एक बार स्टैशेस साफ करें। git stash list चलाएँ और एक हफ्ते से पुराने कुछ भी ड्रॉप करें। सात दिनों में जिसकी जरूरत नहीं पड़ी, शायद आगे भी नहीं पड़ेगी।

3. अपने स्टैश काउंट को पाँच से ऊपर न जाने दें। पाँच से ज्यादा का मतलब आप उन्हें अस्थायी की बजाय दीर्घकालिक स्टोरेज बना रहे हैं। या तो पॉप करें, कमिट करें, या ड्रॉप करें।

4. अगर टीम में कोई पूछे, "वह कोड कहाँ है जिस पर आप काम कर रहे थे?", तो कभी न कहें, "मेरे स्टैश में"। स्टैश निजी और अस्थायी हैं - वे साझा करने या महत्वपूर्ण काम को आर्काइव करने के लिए नहीं।

निष्कर्ष

अब आप जानते हैं कि git stash pop कैसे काम करता है और कब उपयोग करना है।

मूल रूप से, स्टैशिंग सरल है: अपना बिना कमिट किया काम सेव करें, कॉन्टेक्स्ट बदलें, और बाद में बहाल करें। लेकिन विवरण मायने रखते हैं। pop बनाम apply कब उपयोग करना है, कॉन्ट्फ्लिक्ट कैसे संभालने हैं, और कब स्टैश से ब्रांच बनानी है - यह जानना आपको झुंझलाहट से घंटे बचाएगा।

सबसे महत्वपूर्ण बात यह कि स्टैश अस्थायी स्टोरेज है, स्थायी बैकअप नहीं। वर्णनात्मक मैसेज उपयोग करें, नियमित रूप से सफाई करें, और स्टैक को पाँच एंट्रीज़ से आगे न बढ़ने दें। यदि काम साझा करना हो या लंबे समय तक रखना हो, तो उसे किसी ब्रांच पर कमिट करें।

अगर आपको यह लेख पसंद आया और आप Git में बेहतर होना चाहते हैं, तो आगे के बेहतरीन स्टॉप हैं हमारे Intermediate Git और Intermediate GitHub Concepts कोर्स।