यदि आपने अपने Mac पर किसी Git प्रोजेक्ट में कोई फ़ाइल स्टेज कर दी है, लेकिन उसे अगले कमिट से बाहर रखना चाहते हैं, तो Terminal से उस फ़ाइल के लिए git restore --staged चलाएं। यह Git के स्टेजिंग क्षेत्र को अपडेट करता है जबकि फ़ाइल को आपके वर्किंग फ़ोल्डर में छोड़ देता है, ताकि इसके बदलाव बाद में समीक्षा करने या स्टेज करने के लिए उपलब्ध रहें। कमिट करने से पहले फ़ाइल पाथ की जांच करें और git status के साथ परिणाम की पुष्टि करें।

“अनस्टेज” करने से क्या बदलता है

Git प्रस्तावित अगले कमिट को अपने इंडेक्स में रखता है, जिसे स्टेजिंग क्षेत्र भी कहा जाता है। एक कमिट में आम तौर पर स्टेज किए गए बदलाव शामिल होते हैं; जिन बदलावों को आपने स्टेज नहीं किया है वे आपके वर्किंग ट्री में बने रहते हैं। इसलिए इंडेक्स से किसी फ़ाइल को हटाने से वह बदल जाता है जो कमिट के लिए तैयार किया गया है, बिना Git को वर्किंग कॉपी को फिर से लिखने के लिए कहे। Git के दस्तावेज़ों के अनुसार git restore --staged डिफ़ॉल्ट रूप से HEAD से इंडेक्स को पुनर्स्थापित (restore) करता है। Git का restore दस्तावेज़

यह तब उपयोगी होता है जब आपने गलती से गलत फ़ाइल स्टेज कर दी हो, या तय किया हो कि किसी एक फ़ाइल को कमिट से बाहर रहना चाहिए। जब आप इसे एक पाथ देते हैं तो यह कमांड फ़ाइल-विशिष्ट (file-specific) होती है। --worktree न जोड़ें: Git के दस्तावेज़ों का कहना है कि --staged और --worktree दोनों का उपयोग करने से दोनों स्थान पुनर्स्थापित हो जाते हैं, जो कि तब आपका लक्ष्य नहीं होता जब आप अपने बदलावों को रखना चाहते हैं।

Terminal से एक फ़ाइल को अनस्टेज करें

अपने Mac पर Terminal खोलें और रिपॉजिटरी फ़ोल्डर में जाएं। Terminal का डिफ़ॉल्ट शेल zsh है, हालांकि किसी प्रबंधित Mac पर एक अलग शेल का उपयोग हो सकता है। Apple की Terminal गाइड

पहले git status चलाएं। “Changes to be committed” के तहत स्टेज की गई फ़ाइल ढूंढें और रिपॉजिटरी रूट के सापेक्ष इसके पाथ को नोट करें। यदि आपको कोई भिन्न रिपॉजिटरी दिखाई देती है या पाथ स्पष्ट नहीं है, तो कुछ भी बदलने से पहले रुकें और अपने स्थान की जांच करें।

उदाहरण के लिए, src/Feature.swift को अनस्टेज करने के लिए, चलाएं:

git restore --staged -- src/Feature.swift

-- विकल्पों को पाथ से अलग करता है। यह उन नामों के लिए मददगार है जिन्हें अन्यथा विकल्पों के रूप में पढ़ा जा सकता है। स्पेस वाले पाथ को कोट्स में रखें ताकि zsh पाथ को एक तर्क (argument) के रूप में पास करे:

git restore --staged -- "Documentation/Setup Notes.md"

पाथ का उपयोग ठीक वैसे ही करें जैसे Git इसे रिपोर्ट करता है, जिसमें कैपिटलाइज़ेशन और कोई भी डायरेक्टरी नाम शामिल हैं। यदि आप पहले से ही रिपॉजिटरी की सबडायरेक्टरी के अंदर हैं, तो Git पाथ हैंडलिंग कम स्पष्ट हो सकती है; रिपॉजिटरी रूट से कमांड चलाने और पूर्ण रिपॉजिटरी-रिलेटिव पाथ का उपयोग करने से लक्ष्य को सत्यापित करना आसान हो जाता है।

पुष्टि करें कि बदलाव अभी भी मौजूद हैं

फिर से git status चलाएं। किसी ट्रैक्ड, संशोधित फ़ाइल के लिए, स्टेज किया गया बदलाव “Changes to be committed” से गायब हो जाना चाहिए और “Changes not staged for commit” के तहत दिखाई देना चाहिए। इसका मतलब है कि वर्किंग कॉपी अभी भी HEAD से भिन्न है, लेकिन इंडेक्स में अब वह प्रस्तावित बदलाव नहीं है। Git स्टेटस को HEAD और इंडेक्स के बीच, और इंडेक्स और वर्किंग ट्री के बीच बदलाव दिखाने के रूप में वर्णित करता है। Git का add दस्तावेज़

आप अनस्टेज किए गए बदलावों का निरीक्षण इसके साथ कर सकते हैं:

git diff -- "src/Feature.swift"

यह diff वर्किंग फ़ाइल की तुलना इंडेक्स से करता है। क्योंकि उस ट्रैक्ड फ़ाइल के लिए इंडेक्स अब HEAD से मेल खाता है, यह उन सुरक्षित रखे गए बदलावों को दिखाता है जिन्हें आपने स्टेजिंग से हटाया था। फ़ाइल को बाद के कमिट के लिए तैयार करने के लिए, इसे git add -- "src/Feature.swift" के साथ फिर से स्टेज करें।

नई फ़ाइलों और विलोपन (deletions) के मामले में क्या उम्मीद करें

यदि फ़ाइल नई है और इसे कभी कमिट नहीं किया गया है, तो HEAD में इसका कोई संस्करण नहीं होता है। git restore --staged -- path/to/new-file द्वारा इसे इंडेक्स से हटाने के बाद, फ़ाइल को डिस्क पर एक अनट्रैक्ड फ़ाइल के रूप में बने रहना चाहिए। जांचें कि यह git status में “Untracked files” के तहत दिखाई दे रही है; यदि आप इसे रखना चाहते हैं तो इसे हटाएं नहीं।

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

यदि आपने फ़ाइल का केवल कुछ हिस्सा स्टेज किया है

यही कमांड फ़ाइल की स्टेज की गई सामग्री को पूरी तरह से अनस्टेज कर देती है। यदि आपने जानबूझकर कुछ हंक्स (hunks) स्टेज किए हैं और केवल चुनिंदा हंक्स को ही स्टेज रखना चाहते हैं, तो पूरी फ़ाइल वाली कमांड न चलाएं। Git का restore कमांड इंटरैक्टिव पैच मोड का समर्थन करता है, लेकिन सही दिशा और हंक्स का चयन करने में सावधानी की आवश्यकता होती है। इसका उपयोग करने से पहले Git के प्रलेखित git restore --patch व्यवहार की समीक्षा करें; Git स्टेज करने के लिए हंक्स को इंटरैक्टिव रूप से चुनने के लिए git add --patch का भी दस्तावेज़ीकरण करता है। Git का restore दस्तावेज़

इस कार्य के लिए git restore --worktree या git restore --staged --worktree से बचें। वे विकल्प वर्किंग ट्री को प्रभावित करते हैं और उन्हीं बदलावों को हटा सकते हैं जिन्हें आप रखने की कोशिश कर रहे हैं। यदि git status में परिणाम आपकी अपेक्षा से भिन्न है, तो कोई अन्य रिस्टोर कमांड चलाने से पहले रुकें और पाथ तथा diff का निरीक्षण करें।

स्रोत