Git में परिवर्तन को त्यागने के लिए प्रतीत नहीं हो सकता


125

कमांड लाइन से निम्नलिखित को देखने के बाद:

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

मैं कमांड टाइप करके अपने परिवर्तनों को छोड़ने का प्रयास कर रहा हूं:

git checkout -- index.htm

लेकिन जब मैं गिट की स्थिति को फिर से चलाता हूं, तो यह बिल्कुल वैसा ही दिखता है। चेकआउट काम नहीं कर रहा है। क्या मुझसे कुछ गलत हो रही है? मैं जीआईटी 1.6.1.2 का उपयोग विंडोज़ / साइबरविन पर कर रहा हूं।

# On branch RB_3.0.10
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   index.htm

4
क्या git checkout HEAD -- index.htm(इंडेक्स से चेक करने के बजाय अंतिम प्रतिबद्ध अवस्था से जाँच करता है) काम करता है?
जकुब नारबस्की

3
git checkout HEAD -- index.htmमेरे लिए काम किया!
बेन टाइड्सवेल

जवाबों:


52

यह मुझे थोड़ी देर के लिए परेशान कर रहा है, लगभग हर रेपो मैं देख सकता हूं कि उनमें बदलाव थे जिन्हें मैं नहीं छोड़ सकता था। लंबी कहानी छोटी, मैंने उपरोक्त सभी की कोशिश की, कुछ भी काम नहीं किया। यह वही है जो मैंने सामान्य (मैक पर) चीजों को वापस पाने के लिए किया था:

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard

7
ऊपर सब कुछ आज़माने के बाद, यह केवल एक चीज थी जिसने मेरे लिए (विंडोज पर) काम किया
एंडर्स

धन्यवाद! एंडर्स ने जैसा बताया, यह समाधान मेरे लिए भी काम कर रहा है। मैंने # ऑटोक्रॉफ्ट
डेविड

37

यहाँ मेरा अनुभव है, निम्नलिखित चर सेट करें .git/config:

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

फिर चला $ git checkout HEAD ., और यह काम करता है। लेकिन $ git checkout -- .नहीं, अजीब है!

* git संस्करण 1.9.3


35

git diffफ़ाइल में क्या परिवर्तन दिखाई देता है? खिड़कियों पर, मैंने इस तरह के मुद्दों के कारण लाइन-एंडिंग के साथ मुद्दों को देखा है। उस मामले में, क्या आप के लिए है सेटिंग देखना git config core.autocrlfऔर git config core.safecrlfइन सेटिंग्स के लिए यहाँ कुछ प्रलेखन है

मैं कहूंगा, यदि आप git svnतोड़फोड़ के साथ एकीकरण के लिए उपयोग कर रहे हैं , तो सुनिश्चित करें कि autocrlfबंद है। मैं जो बता सकता हूं वह इस कॉन्फ़िगरेशन में बस टूट गया है और यह अधिकांश टूल को लगता है कि फाइलें बदल दी गई हैं, जब आपने checkoutकिसी भी परिवर्तन को वापस करने के लिए किया है ।

यदि आप कोई समस्या देख रहे हैं git checkout, जहाँ आप करते हैं , और फिर git statusदिखाता है कि फ़ाइल अभी भी संशोधित है, और git diffफ़ाइल को फ़ाइल में प्रत्येक पंक्ति में संशोधित किया गया है, तो यह वह समस्या है जिसे आप देख रहे हैं।

core.autocrlf

यदि सही है, फाइल सिस्टम से पढ़ते समय पाठ फ़ाइलों में लाइनों के अंत में CRLF को git कन्वर्ट करता है, और फाइल सिस्टम में लिखते समय रिवर्स में परिवर्तित होता है। चर को इनपुट पर सेट किया जा सकता है, जिस स्थिति में रूपांतरण केवल फ़ाइल सिस्टम से पढ़ते समय होता है लेकिन फ़ाइलों को लाइनों के अंत में LF के साथ लिखा जाता है। वर्तमान में, "पाठ" पर विचार करने के लिए कौन सा मार्ग है (अर्थात आटोक्रॉफ़ल तंत्र के अधीन होना चाहिए) विशुद्ध रूप से सामग्री के आधार पर तय किया जाता है।

core.safecrlf

यदि सही है, तो CRLF को core.autocrlf के रूप में परिवर्तित करने पर गिट चेक बनाता है, यह प्रतिवर्ती है। यदि कोई कमांड सीधे या अप्रत्यक्ष रूप से कार्य ट्री में एक फाइल को संशोधित करता है, तो Git सत्यापित करेगा। उदाहरण के लिए, उसी फ़ाइल की जाँच करने के बाद एक फाइल करने से काम के पेड़ में मूल फ़ाइल निकलनी चाहिए। यदि यह core.autocrlf की वर्तमान सेटिंग के मामले में नहीं है, तो git फ़ाइल को अस्वीकार कर देगा। चर को "चेतावनी" पर सेट किया जा सकता है, जिस स्थिति में गिट केवल एक अपरिवर्तनीय रूपांतरण के बारे में चेतावनी देगा लेकिन ऑपरेशन जारी रखेगा। ...


core.autocrlf = true core.safecrlf सेट नहीं किया गया है। क्या यह विंडोज़ के लिए सही होना चाहिए? दोनों के बीच अंतर क्या है?

मैं कहूंगा, यदि आप git svn का उपयोग कर रहे हैं तो उन दोनों को छोड़ दें। मैंने कुछ और विस्तार से जोड़ा।
1800 सूचना

4
मुझे लगता है कि वह इसका मतलब है कि इसे कम से कम 90 डिग्री
vijrox

2
जब मैंने core.autocrlf और core.safecrlf दोनों को सच में सेट किया, तो मैंने 'git reset --hard HEAD' चलाकर आपत्तिजनक फाइलों में पाया गया बदलावों को छोड़ दिया।
अलेक्सी

19

मुझे लगता है कि आपको पास होने की आवश्यकता है -f

मैन पेज से ( man git-checkout, GIT-CHECKOUT (1)):

-f, - लागू करें
भले ही सूचकांक या काम करने वाला पेड़ HEAD से भिन्न हो।
इसका उपयोग स्थानीय परिवर्तनों को दूर करने के लिए किया जाता है

उदाहरण के लिए, वर्तमान शाखा में परिवर्तन छोड़ दें और किसी भिन्न शाखा में स्विच करें:

git checkout -f master

7
पास-ऑफ क्या? जवाब को पूरा करने के लिए अच्छा होगा
पांडावुड

@ मेरा इरादा एक अलग शाखा की जाँच करने का नहीं था। जवाब 2009 से है तो मुझे वास्तव में याद नहीं है लेकिन इस सवाल को देखते हुए, मुझे लगता है कि मुझे -fचेकआउट करने का मतलब था - <filename> जैसा किgit checkout -f -- filename
hasen

@ यह तीन टिप्पणियाँ आप स्पष्टीकरण के लिए पूछ रहे थे, यही वजह है कि मैंने "उदाहरण के लिए" जोड़ा। उदाहरण -f
मैट एच

मेरे लिए काम किया। git checkout -f master"पहले से ही 'मास्टर' पर फेंक दिया, लेकिन परिवर्तन चले गए थे।
ईसाई

12

यह लाइन अंत हो सकता है, जैसा कि @ 1800- जानकारी से पता चलता है, लेकिन एक और संभावना यह है कि अंतर (जो कि इन फ़ाइलों को चेकआउट कमांड से बदलने से रोक रहा है) फ़ाइल मोड में से एक है। मेरा साथ ऐसा ही हुआ था। मेरे git के संस्करण पर आप इसका उपयोग करके खोज सकते हैं

git diff index.htm

और यह आपको फ़ाइल मोड परिवर्तन दिखाएगा। यह अभी भी आपको उन्हें वापस नहीं आने देगा, हालांकि, चेकआउट का उपयोग करते हुए, यहां तक ​​कि -f विकल्प के साथ भी। उस उपयोग के लिए या तो

git config core.filemode false

या जोड़कर अपने पाठ संपादक में अपना git .config बदलें

[कोर]

filemode = false

ऐसा करने के बाद, आप उपयोग कर सकते हैं

git रीसेट HEAD index.htm

और फ़ाइल गायब हो जानी चाहिए।

(मुझे यह सब जवाबों से मिला कि कैसे मैं git को मोड परिवर्तन (chmod) अनदेखा करता हूं? और अपडेट-फाइल-परमिशन-केवल-इन-गिट )


बहुत बहुत धन्यवाद! फ़ाइल मोड परिवर्तनों से छुटकारा पाने के लिए किसी भी अन्य सुझाव ने मेरे लिए काम नहीं किया।
थोरिल वोरगे

6

क्या आप OSX या विंडोज पर हैं? यदि हां, तो समस्या संभवतः एक ही नाम की दो फ़ाइलों के साथ है, अलग-अलग मामले के साथ। जैसे। index.htm और index.htm

विंडोज़, और डिफ़ॉल्ट रूप से OSX, केस असंवेदनशील फाइल सिस्टम का उपयोग करता है, जो केस सेंसिटिव गिट के साथ टकराव करता है।


2

मेरे पास यह मुद्दा था और उपरोक्त सभी की कोशिश करने के बाद, कुछ भी काम नहीं किया।

मेरे लिए जो काम किया गया था वह उस डायरेक्टरी को डिलीट करना था जो फाइल में थी, फिर किया git statusऔर यह सुनिश्चित किया कि उस डायर की सभी फाइलें अब डिलीट हो गई हैं। उसके बाद मैंने बस किया git checkout -fऔर सब कुछ सामान्य हो गया।


1

मैं एक libGDXपरियोजना पर काम कर रहा था Android Studioऔर मैं अपने द्वारा किए गए सभी परिवर्तनों को छोड़ना चाहता था, और मेरे लिए कुछ भी काम नहीं कर रहा था, मैं जिस समाधान के साथ आया था वह सभी परिवर्तनों को एक नई शाखा में शामिल करना था

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

और फिर आप चाहें तो TRASHशाखा को हटा सकते हैं।


1

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

  • मुझे दूसरे कंप्यूटर से एक फाइल को हटाना पड़ा और उसे रेपो में धकेलना पड़ा

  • पूरे स्थानीय संस्करण को पूरी तरह से हटा दें

  • खरोंच से क्लोन क्लोन करें


0

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

git checkoutऔर छोड़ने की कोशिश करने से कोई फायदा नहीं हुआ। यह काम नहीं करेगा या यह मुझे बताएगा कि मेरे पास अनुमति नहीं है।

समाधान जो काम किया:

  1. सेफ मोड में जाएं
  2. फ़ाइलों को त्यागें

पुनरारंभ करना एक दर्द है, लेकिन इसने 100 चीजों को आज़माने की तुलना में तेजी से काम किया।


0

एक आसान उपाय है। यदि ऐसा होता है (आम तौर पर अनपेक्षित विंडोज़ शटडाउन या मेमोरी डंप से) और आप अपने परिवर्तनों को नहीं छोड़ सकते हैं और यहां तक ​​कि शाखाओं के बीच स्विच कर सकते हैं (Git का कहना है कि आपके पास पर्याप्त अनुमति नहीं है); फ़ोल्डर विकल्पों से Windowsवातावरण में show all hidden files and folders। अपनी जीआईटी निर्देशिका पर जाएं (शुरू होना चाहिए .git) और "index.lock"फ़ाइल को हटा दें । फिर Git को आपको वह करने देना चाहिए जो आप करना चाहते हैं।


0

मैं कुछ से छुटकारा पाने के लिए एक git stashपीछा कर रहा था git stash clean। किसी भी ऑटो करोड़ / lf विन्यास को .it / या ~ / .ITIT सामान में नहीं देखा था।


0

मेरे मामले में मैं एक निर्देशिका से संबंधित परिवर्तनों को नहीं छोड़ सकता। उदाहरण के लिए, जब मैंने दौड़ लगाई, तो मैं यह देखूंगा: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

इसलिए मैंने उस निर्देशिका को बुलाया और वहाँ एक git स्टेटस चलाया। यह एक HEAD अलग राज्य में था। और फिर मैं बस git checkout masterवहाँ भाग गया । मेरे लिए यह सही है। लेकिन इसमें पूछे गए सटीक परिदृश्य के लिए यह उपयोगी नहीं है।


0

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

git status update

यही कारण है कि चाहिए ठीक बातें मदद (इस विशेष मामले में)


0

मुझे विंडोज़ में अनुमतियों की समस्या थी और मुझे icacls containingFolder /reset /t /l /cअपनी अनुमति वापस लेने के लिए फ़ोल्डर को डबल-क्लिक करना था ।


0

मेरे पास निम्न सामग्री के साथ .itattributes है:

* text=auto eol=lf

समस्या .gitattributesको दूर करने के लिए, इस लाइन को हटाने के लिए संपादित करें जो लाइन एंडिंग्स को आराम देता है। फिर git reset --hard HEADफ़ाइलों और .gitattributesफ़ाइल को वापस कर दिया ।


0

मेरे लिए यह मुद्दा एक Git-LFS छवि को डाउनलोड करने के संयोजन के साथ आया था जिसे Netlify CMS के माध्यम से अपलोड किया गया था और उनके Netlify बड़े मीडिया हैंडलर द्वारा अलग-अलग तरीके से परोसा गया था।

मेरा हल यह था कि इन पंक्तियों को मेरी टिप्पणी से हटा दें / हटा दें ~/.gitconfigताकि वे नीचे की तरह दिखें, और फिर git statusदोबारा जाँच करें।

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

या आप शायद .gitconfigरेपो रूट में एक के माध्यम से एक और अधिक स्थानीय फिल्टर जोड़ सकते हैं और किसी तरह वहां के लिए फिल्टर नियमों को ओवरराइट कर सकते हैं।

आशा है कि यह एक साथी की मदद करता है।


-1

मैंने भी कुछ इसी तरह की समस्या का सामना किया और निम्नलिखित कदमों ने मेरी मदद की:

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

आशा है कि यह अन्य लोगों की भी मदद करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.