सवाल प्रतिबद्ध होने से पहले 'गिट एड' पूर्ववत कैसे करें?


मैंने गलती से कमांड का उपयोग करके गिट में फाइलें जोड़ दीं:

git add myfile.txt

मैंने अभी तक भाग नहीं लिया है git commit। क्या इसे पूर्ववत करने का कोई तरीका है, इसलिए इन फ़ाइलों को प्रतिबद्धता में शामिल नहीं किया जाएगा?


अभी तक 48 उत्तरों हैं (कुछ हटाए गए हैं)। कृपया एक नया न जोड़ें जब तक कि आपके पास कुछ नई जानकारी न हो।


7464
2017-12-07 21:57


मूल


गिट v1.8.4 से शुरू, उस उपयोग के नीचे सभी उत्तरों HEAD या headअब उपयोग कर सकते हैं @ की जगह में HEAD बजाय। देख यह उत्तर (अंतिम खंड) यह जानने के लिए कि आप ऐसा क्यों कर सकते हैं।
मैंने एक छोटा सा सारांश बनाया जो फ़ाइल को अस्थिर करने के सभी तरीकों को दिखाता है: stackoverflow.com/questions/6919121/... - Daniel Alder
गिट चेकआउट क्यों नहीं? - Erik Reppen
@ErikReppen git checkout प्रतिबद्ध अनुक्रमणिका से चरणबद्ध परिवर्तनों को हटा नहीं है। यह केवल अंतिम प्रतिबद्ध संशोधन में अन-चरणबद्ध परिवर्तनों को उलट देता है - जिस तरह से मैं वही नहीं चाहता हूं, मैं उन परिवर्तनों को चाहता हूं, मैं उन्हें बाद में प्रतिबद्धता में चाहता हूं। - paxos1977
यदि आप ग्रहण का उपयोग करते हैं, तो यह प्रतिबद्ध संवाद बॉक्स में फ़ाइलों को अनचेक करना उतना आसान है - Hamzahfrq


जवाब:


आप पूर्ववत कर सकते हैं git add प्रतिबद्ध करने से पहले

git reset <file>

जो इसे किसी अन्य चीज़ को बदले बिना मौजूदा इंडेक्स ("प्रतिबद्ध होने के बारे में" सूची) से हटा देगा।

आप उपयोग कर सकते हैं

git reset

सभी उचित परिवर्तनों को अस्थिर करने के लिए किसी फ़ाइल नाम के बिना। यह तब आसान हो सकता है जब उचित फाइलों में एक से अधिक फ़ाइलों को सूचीबद्ध किया जा सके।

गिट के पुराने संस्करणों में, उपरोक्त आदेश बराबर हैं git reset HEAD <file> तथा git reset HEAD क्रमशः, और अगर विफल हो जाएगा HEAD अनिर्धारित है (क्योंकि आपने अभी तक अपने रेपो में कोई काम नहीं किया है) या संदिग्ध (क्योंकि आपने एक शाखा बनाई है HEAD, जो एक बेवकूफ चीज है जिसे आपको नहीं करना चाहिए)। इस गिट 1.8.2 में बदल दिया गया थाहालांकि, गिट के आधुनिक संस्करणों में आप अपनी पहली प्रतिबद्धता से पहले उपरोक्त आदेशों का उपयोग कर सकते हैं:

"गिट रीसेट" (विकल्प या पैरामीटर के बिना) त्रुटि के लिए उपयोग किया जाता है      आपके पास आपके इतिहास में कोई काम नहीं है, लेकिन अब यह आपको देता है      एक खाली सूचकांक (मौजूदा अस्तित्व से मेल खाने के लिए आप यहां भी नहीं हैं)।


8379
2017-12-07 22:30



बेशक, यह सच पूर्ववत नहीं है, क्योंकि गलत है git add पिछले चरणबद्ध असामान्य संस्करण को ओवरराइट करें, हम इसे पुनर्प्राप्त नहीं कर सकते हैं। मैंने नीचे दिए गए मेरे उत्तर में इसे स्पष्ट करने की कोशिश की। - leonbloy
git reset HEAD *.ext कहा पे ext दी गई एक्सटेंशन की फ़ाइलें हैं जिन्हें आप अनदेखा करना चाहते हैं। मेरे लिए यह था *.bmp और *.zip - boulder_ruby
@ जॉनी, सूचकांक (उर्फ स्टेजिंग क्षेत्र) में शामिल हैं सब फाइलें, न सिर्फ फाइलें बदलीं। हेड द्वारा इंगित प्रतिबद्धता में सभी फाइलों की एक प्रति के रूप में यह "जीवन शुरू करता है" (जब आप एक प्रतिबद्धता की जांच करते हैं या एक रेपो क्लोन करते हैं)। तो फिर आप हटाना सूचकांक से एक फाइल (git rm --cached) इसका मतलब है कि आप प्रतिबद्ध करने की तैयारी कर रहे हैं हटाए गए वह फाइल git reset HEAD <filename> दूसरी तरफ फ़ाइल को हेड से इंडेक्स में कॉपी कर देगा, ताकि अगली प्रतिबद्धता उस फ़ाइल में किए गए कोई भी बदलाव नहीं दिखाएगी। - Wildcard
मैंने अभी पाया कि एक है git reset -p बिलकुल इसके जैसा git add -p। यह कमाल का है! - donquixote
आप वास्तव में पहले चरणबद्ध लेकिन असामान्य परिवर्तन overwriten पुनर्प्राप्त कर सकते हैं लेकिन उपयोगकर्ता मित्रतापूर्ण तरीके से नहीं और 100% सुरक्षित नहीं (कम से कम मुझे नहीं मिला): goto .git / ऑब्जेक्ट्स, उस समय बनाई गई फ़ाइलों के लिए खोजें git add आप ठीक करना चाहते हैं (61/3AF3... -> ऑब्जेक्ट आईडी 613AF3...), फिर git cat-file -p <object-id> (कई घंटों के काम को ठीक करने के लिए इसके लायक हो सकते हैं लेकिन अधिक बार प्रतिबद्ध करने के लिए एक सबक भी ...) - Peter Schneider


तुम्हें चाहिए:

git rm --cached <added_file_to_undo>

तर्क:

जब मैं यह नया था, मैंने पहली बार कोशिश की

git reset .

(मेरे पूरे प्रारंभिक एड को पूर्ववत करने के लिए), केवल यह प्राप्त करने के लिए (ऐसा नहीं) उपयोगी संदेश:

fatal: Failed to resolve 'HEAD' as a valid ref.

यह पता चला है कि ऐसा इसलिए है क्योंकि पहली प्रतिबद्धता के बाद तक HEAD रेफरी (शाखा?) मौजूद नहीं है। यही है, आप मेरे जैसे ही शुरुआती समस्या में भाग लेंगे, जैसे मेरा वर्कफ़्लो, मेरी तरह कुछ था:

  1. गिट, नई गर्मी की कोशिश करने के लिए मेरी महान नई परियोजना निर्देशिका में सीडी
  2. git init
  3. git add .
  4. git status

    ... द्वारा बकवास स्क्रॉल के बहुत सारे ...

    => अरे, मैं उन सभी को जोड़ना नहीं चाहता था।

  5. गूगल "पूर्ववत गिट एड"

    => स्टैक ओवरफ़्लो ढूंढें - हाँ

  6. git reset .

    => घातक: वैध रेफरी के रूप में 'HEAD' को हल करने में विफल।

यह आगे पता चला है कि वहाँ है एक बग लॉग इन मेलिंग सूची में इसकी अनुपस्थिति के खिलाफ।

और यह कि गिट स्टेटस आउटपुट में सही समाधान सही था (जो, हां, मैंने 'बकवास' के रूप में चमक लिया

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

और वास्तव में समाधान का उपयोग करना है git rm --cached FILE

यहां कहीं और चेतावनियों पर ध्यान दें - git rm फ़ाइल की अपनी स्थानीय कामकाजी प्रति हटा देता है, लेकिन नहीं यदि तुम प्रयोग करते हो --cached। इसका परिणाम यहां दिया गया है git help rm:

--cached       इंडेक्स से केवल पथ को अस्थिर करने और हटाने के लिए इस विकल्प का उपयोग करें।       वर्किंग पेड़ फाइलें, चाहे संशोधित हों या नहीं, छोड़े जाएंगे।

मैं उपयोग करने के लिए आगे बढ़ता हूं

git rm --cached .

सबकुछ हटाने और फिर से शुरू करने के लिए। हालांकि काम नहीं किया, क्योंकि जबकि add . रिकर्सिव है, बाहर निकलता है rm ज़रूरत -r रिकर्स करने के लिए। आह।

git rm -r --cached .

ठीक है, अब मैं वापस आ गया हूं जहां मैंने शुरू किया था। अगली बार मैं उपयोग करने जा रहा हूँ -n एक सूखा दौड़ करने के लिए और देखें कि क्या जोड़ा जाएगा:

git add -n .

मैं भरोसा करने से पहले सब कुछ एक सुरक्षित जगह पर ज़िपित किया git help rm बारे में --cached कुछ भी नष्ट नहीं करना (और अगर मैंने इसे गलत वर्तनी दी)।


1954
2018-03-25 16:20



हा। मैंने इसी प्रक्रिया का पालन किया। छोड़कर मैंने छोड़ दिया और कहा rm -rf .git, git init क्योंकि मुझे विश्वास नहीं था git rm --cached मेरी कामकाजी प्रतिलिपि रखने के लिए। यह कहता है कि कुछ जगहों पर गिट अभी भी काफी जटिल है। git unstage सिर्फ एक स्टॉक मानक कमांड होना चाहिए, मुझे कोई परवाह नहीं है अगर मैं इसे उपनाम के रूप में जोड़ सकता हूं। - Adrian Macneil
मेरे लिए गिट कहते हैं git reset HEAD <File>... - drahnr
git rm --cached <file> वास्तव में सही उत्तर है, अगर यह भंडार में <file> का प्रारंभिक आयात है। यदि आप फ़ाइल में बदलाव को अस्थिर करने का प्रयास कर रहे हैं, तो गिट रीसेट सही उत्तर है। लोग कहते हैं कि यह जवाब गलत है एक अलग सवाल के बारे में सोच रहे हैं। - Barry Kelly
यह वास्तव में काम करेगा, लेकिन केवल पहली प्रतिबद्धता पर, जहां फ़ाइल पहले मौजूद नहीं थी, या कहां थी git add कमांड ने नई फाइलें जोड़ दीं, लेकिन नहीं मौजूदा फाइलों में परिवर्तन। - naught101
यह दिखाने के लिए चला जाता है कि कैसे अनजान और गठित गिट है। समांतर "पूर्ववत करें" आदेशों के बजाय, आपको यह पता लगाना होगा कि उन्हें पूर्ववत कैसे करें। अपने पैर को त्वरित रेत में मुक्त करने की कोशिश करने की तरह, और फिर अपनी बांह फंस गई, फिर अपनी दूसरी भुजा फंस गई ... प्रत्येक आदेश को GUI के माध्यम से किया जाना चाहिए, विकल्पों के लिए ड्रॉपडाउन मेनू आइटम के साथ ... सभी यूआई के बारे में सोचें, हमारे पास उत्पादकता लाभ है, लेकिन हमारे पास रेट्रो कमांड लाइन इंटरफ़ेस का यह गड़बड़ है। यह गिट जीयूआई कार्यक्रमों की तरह नहीं है यह और अधिक अंतर्ज्ञानी बनाते हैं। - ahnbizcad


यदि आप टाइप करते हैं:

git status

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

use "git reset HEAD <file>..." to unstage

मुझे लगता है कि गिट मुझे इस तरह की स्थितियों में सही चीज़ करने के लिए परेशान करने का एक अच्छा काम करता है।

नोट: हालिया गिट संस्करण (1.8.4.x) ने इस संदेश को बदल दिया है:

(use "git rm --cached <file>..." to unstage)

484
2017-12-07 23:22



इस पर निर्भर करता है कि संदेश अलग होगा या नहीं addएड फ़ाइल पहले से ही ट्रैक किया जा रहा था (द add केवल कैश में एक नया संस्करण सहेजा - यहां यह आपका संदेश दिखाएगा)। कहीं और, अगर फ़ाइल पहले मंचित नहीं की गई थी, तो यह प्रदर्शित होगी use "git rm --cached <file>..." to unstage - leonbloy
महान! git reset HEAD <file> एकमात्र ऐसा व्यक्ति है जो एक फ़ाइल हटाए जाने के मामले में काम करेगा - skerit
मेरा गिट संस्करण 2.14.3 कहता है git reset HEAD unstage करने के लिए। - seaturtle


स्पष्टीकरण देना: git add वर्तमान कार्य निर्देशिका से परिवर्तनों को बदलता है मचान क्षेत्र (इंडेक्स)।

इस प्रक्रिया को बुलाया जाता है मचान। तो सबसे प्राकृतिक आदेश मंच परिवर्तन (बदली गई फाइलें) स्पष्ट है:

git stage

git add के लिए उपनाम टाइप करना एक आसान है git stage

दयालुता नहीं है git unstage न git unadd आदेश देता है। प्रासंगिक एक अनुमान लगाना या याद रखना मुश्किल है, लेकिन यह बहुत स्पष्ट है:

git reset HEAD --

हम आसानी से इसके लिए उपनाम बना सकते हैं:

git config --global alias.unadd 'reset HEAD --'
git config --global alias.unstage 'reset HEAD --'

और अंत में, हमारे पास नए आदेश हैं:

git add file1
git stage file2
git unadd file2
git unstage file1

व्यक्तिगत रूप से मैं भी छोटे उपनाम का उपयोग करता हूं:

git a #for staging
git u #for unstaging

220
2017-09-10 20:28



"चाल"? यह इंगित करेगा कि यह कार्यशील निर्देशिका से चला गया है। ऐसा नहीं है। - Thomas Weller
यह स्पष्ट क्यों है? - Lenar Hoyt


स्वीकृत उत्तर में एक अतिरिक्त, यदि आपकी गलती से जोड़ा गया फ़ाइल बहुत बड़ा था, तो आप शायद यह नोटिस करेंगे कि, इसे इंडेक्स से 'git reset', यह अभी भी अंतरिक्ष में कब्जा करने लगता है .git निर्देशिका। यह चिंतित होने के लिए कुछ भी नहीं है, फ़ाइल वास्तव में भंडार में है, लेकिन केवल "ढीली वस्तु" के रूप में, इसे अन्य भंडारों (क्लोन, पुश के माध्यम से) में कॉपी नहीं किया जाएगा, और अंततः अंतरिक्ष को पुनः दावा किया जाएगा - हालांकि शायद बहुत जल्द नहीं। यदि आप चिंतित हैं, तो आप दौड़ सकते हैं:

git gc --prune=now

अद्यतन करें (निम्नलिखित कुछ मतभेदों को दूर करने का मेरा प्रयास क्या है जो सबसे ऊपर दिए गए उत्तरों से उत्पन्न हो सकते हैं):

तो, जो असली है पूर्ववत का git add?

git reset HEAD <file> ?

या

git rm --cached <file>?

कड़ाई से बोलते हुए, और अगर मुझे गलत नहीं लगता है: कोई नहीं

git add  पूर्ववत नहीं किया जा सकता है - सामान्य रूप से, सुरक्षित रूप से।

चलिए पहले याद करते हैं git add <file> वास्तव में करता है:

  1. अगर <file> था पहले ट्रैक नहीं किया गया, git add  इसे कैश में जोड़ता है, इसकी वर्तमान सामग्री के साथ।

  2. अगर <file> था पहले ही ट्रैक किया गया है, git add  वर्तमान सामग्री बचाता है (स्नैपशॉट, संस्करण) कैश में। जीआईटी में, इस कार्रवाई को अभी भी बुलाया जाता है जोड़ना, (न केवल अद्यतन करें यह), क्योंकि फ़ाइल के दो अलग-अलग संस्करण (स्नैपशॉट्स) को दो अलग-अलग आइटम माना जाता है: इसलिए, हम वास्तव में कैश में एक नया आइटम जोड़ रहे हैं, जिसे बाद में अंततः किया जा सकता है।

इस के प्रकाश में, सवाल थोड़ा संदिग्ध है:

मैंने गलती से कमांड का उपयोग कर फाइलें जोड़ दीं ...

ओपी का परिदृश्य पहली (अनचाहे फ़ाइल) प्रतीत होता है, हम ट्रैक किए गए आइटम से फ़ाइल को निकालने के लिए "पूर्ववत करें" चाहते हैं (केवल वर्तमान सामग्री नहीं)। अगर यह मामला है, तो दौड़ना ठीक है git rm --cached <file>

और हम भी भाग सकते थे git reset HEAD <file>। यह सामान्य रूप से बेहतर है, क्योंकि यह दोनों परिदृश्यों में काम करता है: यह पूर्ववत करता है जब हमने गलत तरीके से पहले से ट्रैक किए गए आइटम का संस्करण जोड़ा है।

लेकिन दो चेतावनी हैं।

पहला: जवाब में बताया गया है (जैसा कि उत्तर में बताया गया है) जिसमें केवल एक परिदृश्य है git reset HEAD काम नहीं करता है, लेकिन git rm --cached करता है: एक नया भंडार (कोई काम नहीं करता)। लेकिन, वास्तव में, यह एक व्यावहारिक रूप से अप्रासंगिक मामला है।

दूसरा: जागरूक रहें git reset HEAD  पहले कैश्ड फ़ाइल सामग्री को जादुई रूप से पुनर्प्राप्त नहीं कर सकता है, यह सिर्फ इसे HEAD से पुनर्विक्रय करता है। अगर हमारे गुमराह हो git add पिछले चरणबद्ध असामान्य संस्करण को ओवरराइट करें, हम इसे पुनर्प्राप्त नहीं कर सकते हैं। यही कारण है कि, कड़ाई से बोलते हुए, हम पूर्ववत नहीं कर सकते हैं।

उदाहरण:

$ 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 lost irrevocably "version 2"
-version 1
+version 3

बेशक, यह बहुत महत्वपूर्ण नहीं है अगर हम केवल नई फाइलें (केस 1) जोड़ने के लिए 'गिट एड' करने के सामान्य आलसी वर्कफ़्लो का पालन करते हैं, और हम प्रतिबद्धता के माध्यम से नई सामग्री अपडेट करते हैं, git commit -a आदेश।


137
2018-05-18 18:05



कड़ाई से बोलना एक पहले से ही चरणबद्ध फ़ाइल को पुनर्प्राप्त करने का एक तरीका है जिसे गिट एड के साथ बदल दिया गया था। जैसा कि आप गिट एड का उल्लेख करते हैं, उस फ़ाइल के लिए एक गिट ऑब्जेक्ट बनाता है जो न केवल फाइल को हटाते समय एक नई वस्तु के साथ ओवरराइट होने पर भी ढीला ऑब्जेक्ट बन जाएगा। लेकिन इसे स्वचालित रूप से पुनर्प्राप्त करने के लिए कोई आदेश नहीं है। इसके बजाए फ़ाइल को मैन्युअल रूप से पहचाना जाना चाहिए और मैन्युअल रूप से निकाला जाना चाहिए या केवल इस मामले के लिए लिखे गए टूल के साथ (libgit2 इसे अनुमति देगा)। लेकिन यह केवल तभी भुगतान करेगा जब फ़ाइल बहुत महत्वपूर्ण और बड़ी हो और पिछले संस्करण को संपादित करके पुनर्निर्माण नहीं किया जा सके। - Johannes Matokic
खुद को सही करने के लिए: एक बार ढीली ऑब्जेक्ट फ़ाइल मिलने के बाद (निर्माण दिनांक / समय जैसे मेटा-डेटा का उपयोग करें) git cat-file इसकी सामग्री को पुनर्प्राप्त करने के लिए इस्तेमाल किया जा सकता है। - Johannes Matokic
एक और तरीका है चरणबद्ध परिवर्तनों को पुनर्प्राप्त करें लेकिन प्रतिबद्ध नहीं हैं और फिर ओवरराइट किए गए हैं उदा। एक और git add के माध्यम से है git fsck --unreachable जो सभी पहुंचने योग्य ओबीजे सूचीबद्ध करेगा, जिसका आप निरीक्षण कर सकते हैं git show SHA-1_ID या git fsck --lost-found वह> लटकती वस्तुओं को लिख देगा .git/lost-found/commit/ या .git/lost-found/other/, प्रकार के आधार पर। यह भी देखें git fsck --help - iolsmit


git rm --cached . -r

आपके वर्तमान निर्देशिका से जो कुछ भी आपने जोड़ा है उसे "अन-एड" करें


85
2017-12-09 21:19



मैं सबकुछ जोड़ना नहीं चाहता था, बस एक विशिष्ट फाइल। - paxos1977
यदि आपके पास कोई पिछली प्रतिबद्धता नहीं है तो भी सहायक। पिछली प्रतिबद्धता की अनुपस्थिति में, git reset HEAD <file> कहेगा fatal: Failed to resolve 'HEAD' as a valid ref. - Priya Ranjan Singh
नहीं यह कहते हैं ए विलोपन आपकी वर्तमान निर्देशिका में सब कुछ का। केवल अस्थिर परिवर्तनों के लिए बहुत अलग है। - Mark Amery


रन

git gui

और सभी फ़ाइलों को मैन्युअल रूप से हटाएं या उन सभी को चुनकर और क्लिक करें प्रतिबद्धता से unstage बटन।


77
2017-10-12 01:12



हां मैं समझता हूं। मैं केवल यह स्पष्ट रूप से सुझाव देना चाहता था कि आपका संकेत है कि आपके उत्तर पर "आप इसका उपयोग कर सकते हैं git-gui.... ":) - Alexander Suraphel
यह कहता है, "गिट-गुई: आदेश नहीं मिला"। मुझे यकीन नहीं है कि यह काम करता है। - Parinda Rajapaksha


गिट के पास हर क्रिया के लिए आदेश दिया गया है, लेकिन चीजों को सही करने के लिए व्यापक ज्ञान की आवश्यकता है और इसके कारण यह सर्वोत्तम रूप से प्रतिद्वंद्वी है ...

आपने पहले क्या किया था:

  • एक फ़ाइल बदल दी और इस्तेमाल किया git add ., या git add <file>

आपको क्या चाहिए:

  • इंडेक्स से फ़ाइल को हटाएं, लेकिन वर्किंग कॉपी में असामान्य परिवर्तनों के साथ इसे संस्करणित रखें और छोड़ दें:

    git reset head <file>
    
  • फ़ाइल को HEAD से अंतिम स्थिति में रीसेट करें, परिवर्तनों को पूर्ववत करें और उन्हें अनुक्रमणिका से हटा दें:

    # Think `svn revert <file>` IIRC.
    git reset HEAD <file>
    git checkout <file>
    
    # If you have a `<branch>` named like `<file>`, use:
    git checkout -- <file>
    

    इसके बाद से इसकी आवश्यकता है git reset --hard HEAD एकल फाइलों के साथ काम नहीं करेगा।

  • हटाना <file> इंडेक्स और वर्जनिंग से, वर्किंग कॉपी में बदलाव के साथ गैर संस्करण वाली फ़ाइल को रखते हुए:

    git rm --cached <file>
    
  • हटाना <file> पूरी तरह से काम करने की प्रतिलिपि और संस्करण से:

    git rm <file>
    

73
2018-03-29 11:14



मैं 'गिट रीसेट हेड <file>' और 'git rm --cached <file> के अंतर को खड़ा नहीं कर सकता। क्या आप इसे समझा सकते हैं? - jeswang
@jeswang फ़ाइलें या तो गिट करने के लिए 'ज्ञात' हैं (उनमें परिवर्तनों को ट्रैक किया जा रहा है।), या वे 'संस्करण' नहीं हैं। reset head आपके वर्तमान परिवर्तनों को पूर्ववत करता है, लेकिन फ़ाइल अभी भी गिट द्वारा निगरानी की जा रही है। rm --cached फ़ाइल को वर्जनिंग से बाहर ले जाता है, इसलिए गिट अब बदलावों के लिए इसकी जांच नहीं करता है (और अंत में अनुक्रमित वर्तमान परिवर्तनों को भी हटा देता है, पहले से गिट करने के लिए कहा जाता है add), लेकिन बदली गई फ़ाइल को आपकी कार्यशील प्रतिलिपि में रखा जाएगा, जो आपके अंदर एचडीडी पर फ़ाइल फ़ोल्डर है। - sjas
अंतर है git reset HEAD <file> अस्थायी है - आदेश केवल अगले प्रतिबद्धता पर लागू किया जाएगा, लेकिन git rm --cached <file> जब तक यह फिर से जोड़ा जाता है तब तक unstage होगा git add <file>। इसके अलावा, git rm --cached <file> इसका मतलब है कि यदि आप उस शाखा को रिमोट पर धक्का देते हैं, तो शाखा खींचने वाले किसी भी व्यक्ति को फ़ाइल को उनके फ़ोल्डर से हटा दिया जाएगा। - DrewT


सवाल स्पष्ट रूप से नहीं देखा गया है। कारण यह है कि git add दो अर्थ हैं:

  1. एक जोड़ना नई फ़ाइल स्टेजिंग क्षेत्र में, फिर पूर्ववत करें git rm --cached file
  2. एक जोड़ना संशोधित स्टेजिंग क्षेत्र में फ़ाइल करें, फिर पूर्ववत करें git reset HEAD file

अगर संदेह में, उपयोग करें

git reset HEAD file

क्योंकि यह दोनों मामलों में अपेक्षित चीज करता है।

चेतावनी: यदि तुम करो git rm --cached file एक फाइल पर था संशोधित (एक फ़ाइल जो भंडार में पहले मौजूद थी), तो फ़ाइल को हटा दिया जाएगा git commit! यह अभी भी आपके फाइल सिस्टम में मौजूद होगा, लेकिन अगर कोई और आपकी प्रतिबद्धता खींचता है, तो फाइल उनके काम के पेड़ से हटा दी जाएगी।

git status आपको बताएगा कि फाइल एक थी या नहीं नई फ़ाइल या संशोधित:

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   my_new_file.txt
    modified:   my_modified_file.txt

62
2018-01-16 19:54



+1। इस पृष्ठ पर अत्यधिक अपरिवर्तित उत्तरों और टिप्पणियों की असाधारण संख्या केवल व्यवहार के बारे में गलत है git rm --cached somefile। मुझे उम्मीद है कि यह उत्तर पृष्ठ को एक प्रमुख स्थिति में अपना रास्ता बना देगा जहां यह सभी झूठे दावों से नए लोगों को गुमराह करने से बचा सकता है। - Mark Amery


पूर्ववत करें एक फ़ाइल जो पहले से जोड़ा गया है, का उपयोग करना काफी आसान है Gitरीसेट करने के लिए myfile.txt जो पहले से जोड़ा गया है, उपयोग करें:

git reset HEAD myfile.txt

के बारे में बताएं:

अनचाहे फ़ाइल (ओं) का मंचन करने के बाद, पूर्ववत करने के लिए, आप कर सकते हैं git reset, Head स्थानीय में आपकी फ़ाइल का प्रमुख है और अंतिम पैरामीटर आपकी फ़ाइल का नाम है।

मैं आपके लिए अधिक जानकारी में नीचे दी गई छवि में कदम उठाता हूं, जिसमें इन मामलों में होने वाले सभी चरणों सहित:

git reset HEAD


60
2018-06-28 10:43





यदि आप अपनी प्रारंभिक प्रतिबद्धता पर हैं और आप गिट रीसेट का उपयोग नहीं कर सकते हैं, तो बस "गिट दिवालियापन" घोषित करें और .git फ़ोल्डर को हटाएं और शुरू करें


55
2017-11-19 16:39



फ़ोल्डर को हटाने से पहले, यदि आपने रिमोट मूल जोड़ा है तो अपनी टिप को अपनी .git / config फ़ाइल की प्रतिलिपि बनाना है। - Tiago
@ChrisJohnsen टिप्पणी पर जगह है। कभी-कभी, आप एक को छोड़कर सभी फाइलें करना चाहते हैं: git add -A && git rm --cached EXCLUDEFILE && git commit -m 'awesome commit'  (यह तब भी काम करता है जब कोई पिछली बात नहीं होती है, फिर से Failed to resolve 'HEAD' मुसीबत) - Barry