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




version-control git-commit (20)

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

git add myfile.txt

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

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


अपनी आगामी प्रतिबद्धता से केवल-गयी फ़ाइलों को निकालने के लिए git add -i का उपयोग करें। उदाहरण:

वह फ़ाइल जोड़ना जो आप नहीं चाहते थे:

$ git add foo
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]#

अपने ऐड को पूर्ववत करने के लिए इंटरैक्टिव एड में जा रहे हैं (यहां गिट पर टाइप किए गए कमांड "आर" (रिवर्ट), "1" (सूची रीवर्ट शो में पहली प्रविष्टि), 'रिटर्न' से बाहर निकलने के लिए 'रिटर्न' और "क्यू" (छोड़):

$ git add -i
           staged     unstaged path
  1:        +1/-0      nothing foo

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> r
           staged     unstaged path
  1:        +1/-0      nothing [f]oo
Revert>> 1
           staged     unstaged path
* 1:        +1/-0      nothing [f]oo
Revert>> 
note: foo is untracked now.
reverted one path

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> q
Bye.
$

बस! यहां आपका सबूत है, यह दर्शाता है कि "foo" अनचाहे सूची पर वापस आ गया है:

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]
#       foo
nothing added to commit but untracked files present (use "git add" to track)
$

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

git reset <file>

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

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

git reset

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

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

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


कई अन्य उत्तरों के अनुसार आप git reset उपयोग कर सकते हैं

परंतु:

मुझे यह बहुत छोटी पोस्ट मिली जो वास्तव में गिट git unadd लिए गिट कमांड (अच्छी तरह से उपनाम) git unadd : विवरण के लिए गिट अनैड देखें या ..

सीधे शब्दों में,

git config --global alias.unadd "reset HEAD"

अब आप कर सकते हैं

git unadd foo.txt bar.txt

किसी विशेष फ़ोल्डर (और इसके उपफोल्डर) में प्रत्येक फ़ाइल को रीसेट करने के लिए, आप निम्न आदेश का उपयोग कर सकते हैं:

git reset *

जब आप एक नई परियोजना शुरू करते हैं तो इस परेशानी की समस्या से बचने का एक तरीका यहां दिया गया है:

  • अपनी नई परियोजना के लिए मुख्य निर्देशिका बनाएँ।
  • git init चलाएं।
  • अब एक .gitignore फ़ाइल बनाएं (भले ही यह खाली हो)।
  • अपनी .gitignore फ़ाइल प्रतिबद्ध करें।

यदि आपके पास कोई काम नहीं है तो गिट गिट git reset करना वाकई मुश्किल बनाता है। यदि आप केवल एक होने के लिए एक छोटी प्रारंभिक प्रतिबद्धता बनाते हैं, उसके बाद आप git add -A को git add -A कर सकते git add -A और जितनी बार चाहें उतनी बार git reset कर सकते हैं ताकि सब ठीक हो सके।

इस विधि का एक अन्य लाभ यह है कि यदि आप बाद में लाइन-एंडिंग परेशानियों में भाग लेते हैं और अपनी सभी फ़ाइलों को रीफ्रेश करने की आवश्यकता है, तो यह आसान है:

  • प्रारंभिक प्रतिबद्धता देखें। यह आपकी सभी फाइलों को हटा देगा।
  • फिर फिर से अपना सबसे हालिया प्रतिबद्धता देखें। यह आपकी वर्तमान लाइन-एंडिंग सेटिंग्स का उपयोग करके, आपकी फ़ाइलों की ताजा प्रतियां पुनर्प्राप्त करेगा।

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

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 का नतीजा यहां दिया गया है:

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

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

git rm --cached .

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

git rm -r --cached .

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

git add -n .

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


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

git reset HEAD myfile.txt

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

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

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


बस git reset टाइप करें, यह वापस वापस आ जाएगा और ऐसा लगता है कि आपने कभी भी git add . टाइप नहीं किया है git add . आपकी आखिरी प्रतिबद्धता के बाद से। सुनिश्चित करें कि आपने पहले किया है।


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


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

git status

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

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

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

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

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

शायद आपने अपना प्रश्न पोस्ट करने के बाद गिट विकसित किया है।

$> git --version
git version 1.6.2.1

अब, आप कोशिश कर सकते हैं:

git reset HEAD .

यह वही होना चाहिए जो आप खोज रहे हैं।


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

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

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

git reset HEAD file

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

चेतावनी: यदि आप एक git rm --cached 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

स्पष्टीकरण के लिए: git add वर्तमान कार्य निर्देशिका से स्टेजिंग क्षेत्र (अनुक्रमणिका) में परिवर्तनों को git add है।

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

git stage

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

git unstage कोई git unstage और न ही git unadd आदेशों को 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

स्वीकृत उत्तर में एक अतिरिक्त, यदि आपकी गलती से जोड़ा गया फ़ाइल बहुत बड़ा था, तो आप शायद ध्यान दें कि, इसे ' 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 rm --cached git reset HEAD git rm --cached 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 कमांड के माध्यम से नई सामग्री अपडेट करते हैं।

* (संपादित करें: उपर्युक्त व्यावहारिक रूप से सही है, लेकिन अभी भी कुछ परिवर्तनों को पुनर्प्राप्त करने के लिए कुछ हैकिश / ठोस तरीके हो सकते हैं जो चरणबद्ध थे लेकिन प्रतिबद्ध नहीं थे और फिर ओवरराइट किए गए - जोहान्स मैटोकिक और आईओएसमिट द्वारा टिप्पणियां देखें)


git add myfile.txt # यह आपकी फ़ाइल को प्रतिबद्ध सूची में जोड़ देगा

इस आदेश के काफी विपरीत है,

git reset HEAD myfile.txt  # this will undo it. 

तो, आप पिछले राज्य में होंगे। निर्दिष्ट फिर से अनचाहे सूची (पिछला राज्य) में होगा।

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


एक विशिष्ट फ़ाइल के लिए:

  • git रीसेट my_file.txt
  • गिट चेकआउट my_file.txt

सभी अतिरिक्त फाइलों के लिए:

  • गिट रीसेट।
  • गिट चेकआउट।

नोट: चेकआउट फ़ाइलों में कोड बदलता है और अंतिम अद्यतन (प्रतिबद्ध) स्थिति में जाता है। रीसेट कोड नहीं बदलता है; यह सिर्फ हेडर रीसेट करता है।


मुझे आश्चर्य है कि कोई भी इंटरैक्टिव मोड का उल्लेख नहीं करता है:

git add -i

फ़ाइलों को जोड़ने के लिए विकल्प 3 का चयन करें। मेरे मामले में मैं अक्सर एक से अधिक फाइल जोड़ना चाहता हूं, इंटरैक्टिव मोड के साथ आप फ़ाइलों को जोड़ने के लिए इस तरह की संख्या का उपयोग कर सकते हैं। यह सब कुछ ले जाएगा 4: 1,2,3,5

अनुक्रम चुनने के लिए 1 से 5 तक सभी को लेने के लिए बस 1-5 टाइप करें।

गिट स्टेजिंग फाइलें


यह आदेश आपके परिवर्तनों को मिटा देगा:

git reset HEAD filename.txt

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

git add -p 

फाइलों के हिस्सों को जोड़ने के लिए।


git reset filename.txt

मौजूदा इंडेक्स से filename.txt नाम की एक फ़ाइल को हटाएगा, "कुछ भी करने के लिए" क्षेत्र, बिना किसी बदलाव के।


git reset filename.txt  

मौजूदा इंडेक्स से filename.txt नाम की एक फ़ाइल को हटाएगा, "कुछ भी करने के लिए" क्षेत्र, बिना किसी बदलाव के।





git-stage