स्वीकृत उत्तर के अतिरिक्त, यदि आपकी गलती से जोड़ी गई फ़ाइल बहुत बड़ी थी, तो आप शायद यह नोटिस करेंगे कि, इंडेक्स से इसे हटाने के बाद भी git reset, यह अभी भी .gitडायरेक्टरी में स्थान पर कब्जा कर रहा है ।
यह चिंता की बात नहीं है; फ़ाइल वास्तव में अभी भी भंडार में है, लेकिन केवल "ढीली वस्तु" के रूप में। इसे अन्य रिपॉजिटरी (क्लोन, पुश) के माध्यम से कॉपी नहीं किया जाएगा, और अंतरिक्ष को अंततः पुनः प्राप्त किया जाएगा - हालांकि बहुत जल्द नहीं। यदि आप चिंतित हैं, तो आप दौड़ सकते हैं:
git gc --prune=now
अद्यतन (क्या कुछ भ्रम को दूर करने का मेरा प्रयास है जो सबसे अधिक उत्तर दिए गए प्रश्नों से उत्पन्न हो सकता है):
तो, जो वास्तविक पूर्ववत है git add?
git reset HEAD <file> ?
या
git rm --cached <file>?
सख्ती से बोल रहा हूँ, और अगर मुझसे गलती नहीं है: कोई नहीं ।
git add पूर्ववत नहीं किया जा सकता - सुरक्षित रूप से, सामान्य रूप से।
आइए पहले याद करें कि git add <file>वास्तव में क्या होता है:
यदि पहले ट्रैक नहीं किया<file> गया था , तो इसे अपनी वर्तमान सामग्री के साथ कैश में जोड़ देता है।git add
यदि पहले से ट्रैक किया<file> गया था , तो वर्तमान सामग्री (स्नैपशॉट, संस्करण) को कैश में सहेजता है । गिट में, इस क्रिया को अभी भी ऐड कहा जाता है , (केवल इसे अपडेट नहीं), क्योंकि किसी फ़ाइल के दो अलग-अलग संस्करणों (स्नैपशॉट) को दो अलग-अलग मदों के रूप में माना जाता है: इसलिए, हम वास्तव में कैश में एक नया आइटम जोड़ रहे हैं, अंततः होने के लिए बाद में प्रतिबद्ध।git add
इसके प्रकाश में, सवाल थोड़ा अस्पष्ट है:
मैंने गलती से कमांड का उपयोग करके फाइलें जोड़ दीं ...
ओपी का परिदृश्य पहले वाला (अनटैक्ड फ़ाइल) लगता है, हम ट्रैक किए गए आइटम से फ़ाइल (न केवल वर्तमान सामग्री) को हटाने के लिए "पूर्ववत करना" चाहते हैं। यदि यह मामला है, तो इसे चलाना ठीक है git rm --cached <file>।
और हम भी दौड़ सकते थे git reset HEAD <file>। यह सामान्य रूप से बेहतर है, क्योंकि यह दोनों परिदृश्यों में काम करता है: यह पूर्ववत भी करता है जब हमने गलत तरीके से पहले से ही ट्रैक किए गए आइटम का एक संस्करण जोड़ा था।
लेकिन दो कैविएट हैं।
पहला: वहाँ है (जैसा कि उत्तर में बताया गया है) केवल एक परिदृश्य जिसमें git reset HEADकाम नहीं करता है, लेकिन git rm --cachedयह करता है: एक नया भंडार (कोई सराहनीय नहीं)। लेकिन, वास्तव में, यह एक व्यावहारिक रूप से अप्रासंगिक मामला है।
दूसरा: ध्यान रखें कि git reset HEAD पहले से कैश की गई फ़ाइल सामग्री को जादुई रूप से पुनर्प्राप्त नहीं किया जा सकता है, यह सिर्फ HEAD से इसे फिर से सिंक्रनाइज़ करता है। यदि हमारे गुमराह git addपिछले एक मंचन uncommitted संस्करण overwrote, हम इसे पुनर्प्राप्त नहीं कर सकते। इसीलिए, सख्ती से बोलते हुए, हम पूर्ववत नहीं कर सकते [*]।
उदाहरण:
$ git init
$ echo "version 1" > file.txt
$ git add file.txt # First add of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add file.txt # Stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt
$ git diff file.txt
-version 2
+version 3
$ git add file.txt # Oops we didn't mean this
$ git reset HEAD file.txt # Undo?
$ git diff --cached file.txt # No dif, of course. stage == HEAD
$ git diff file.txt # We have irrevocably lost "version 2"
-version 1
+version 3
बेशक, यह बहुत महत्वपूर्ण नहीं है अगर हम केवल नई फ़ाइलों (केस 1) को जोड़ने के लिए 'git add' करने के सामान्य आलसी वर्कफ़्लो का पालन करते हैं, और हम प्रतिबद्ध, git commit -aकमांड के माध्यम से नई सामग्री अपडेट करते हैं ।
* (संपादित करें: उपरोक्त व्यावहारिक रूप से सही है, लेकिन फिर भी परिवर्तनों को ठीक करने के लिए कुछ थोड़े हैकिश / दृढ़ तरीके हो सकते हैं, लेकिन प्रतिबद्ध नहीं थे और फिर अधिलेखित नहीं हुए - जोहान्स माटॉइक और आईसोलिट द्वारा टिप्पणियां देखें)
HEADयाheadअब इसके@स्थान पर उपयोग कर सकते हैंHEAD। यह जानने के लिए कि आप ऐसा क्यों कर सकते हैं, यह उत्तर (अंतिम खंड) देखें ।