जीआईटी रीसेट के बाद छोड़े गए अनचाहे बदलाव

Question

के बाद git reset --hard, git statusमुझे Changes not staged for commit:अनुभाग के भीतर फाइलें देता है ।

मैंने भी कोशिश की है git reset ., git checkout -- .और git checkout-index -f -a, कोई फायदा नहीं हुआ।

तो, मैं उन अस्थिर परिवर्तनों से कैसे छुटकारा पा सकता हूं?

यह केवल Visual Studio प्रोजेक्ट फ़ाइलों को हिट करने के लिए लगता है। अजीब। : इस पेस्ट देखें http://pastebin.com/eFZwPn9Z । उन फ़ाइलों के साथ क्या खास है, यह है कि मेरे पास .gitattributes में है:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

इसके अलावा, autocrlfमेरे वैश्विक में झूठे के लिए सेट है .gitconfig। कि किसी भी तरह प्रासंगिक हो सकता है?

Comments

क्या आपने उन आदेशों को रिपॉजिटरी की जड़ से लागू किया था? सूचना .वर्तमान निर्देशिका के लिए है न कि रूट डायरेक्टरी

— अलेक्जेंडर

मैंने उन्हें वास्तव में रूट रिपॉजिटरी से किया था।

— नोरवाज N

आपका gitसंस्करण क्या है ? या तो आप एक मूर्खतापूर्ण गलती कर रहे हैं या आपके पास एक पुराना संस्करण है जो छोटी गाड़ी है?

— शहबाज

यह 1.7.4 मिलीमीटर है। यह एक गलती हो सकती है, लेकिन कमांड काफी सरल लगते हैं, और मैं गलती नहीं कर सकता।

— दोपहर

रिकॉर्ड के लिए, मैंने msysgit (1.7.11) के नवीनतम संस्करण का उपयोग करने की कोशिश की, लेकिन समस्या बनी हुई है।

— दोपहर

Answer 1

मुझे भी यही समस्या थी और यह .gitattributesफाइल से संबंधित था । हालाँकि समस्या के कारण फ़ाइल प्रकार निर्दिष्ट नहीं किया गया था .gitattributes।

मैं बस चलाकर मुद्दे को हल करने में सक्षम था

git rm .gitattributes
git add -A
git reset --hard

Comments

यह gitattributes फ़ाइल में * पाठ = ऑटो निर्देश है। यह स्वचालित रूप से फाइल एंडिंग्स को बदल देता है, इसलिए जब आप स्थिति की जांच करेंगे तो फाइलें स्वचालित रूप से "संशोधित" के रूप में चिह्नित की जाएंगी।

— कोडी Django

यह काम करता है, लेकिन मुझे समझ नहीं आता कि क्यों। किसी को भी प्रत्येक कमांड की व्याख्या करने की परवाह है?

— एडविन स्टेलर

@NLwino, git rm .gitattributesइंडेक्स से .itattributes को हटाता है। git add -Aइंडेक्स में सभी (.gitattributes को हटाने सहित) को जोड़ता है, जो कि केवल .gitattributes को हटाना चाहिए , अगर यह वास्तव में समस्या थी। git reset --hardसभी परिवर्तन किए गए परिवर्तनों को रीसेट करता है, जिसमें .gitattributes को निकालना शामिल है। अनिवार्य रूप से, यह * text=autoएक हटाकर इसे कमिट करने के लिए .gitattributes (और निर्देश) को अनदेखा करता है, फिर इसे हटाए जाने के दौरान सूचकांक रीसेट कर रहा है, इसलिए इसे वापस रख रहा है, लेकिन जब आप पहले ही अन्य फ़ाइलों को रीसेट कर लेते हैं, तो वे फिर से संशोधित नहीं किए गए थे।

— बादल

@GameScripting, यह समाधान मेरे लिए काम नहीं करता है। ऐसी कोई फ़ाइल नहीं है जैसे .gitattributes: "घातक: pathspec '। .itattributes' किसी भी फाइल से मेल नहीं खाती"

— Pacerier

मैं ऐसा करता हूं और यह कहता है fatal: pathspec '.gitattributes' did not match any files । मैं क्या गलत कर रहा हूं?

— हनी

Answer 2

यह संकल्प !!!

मैंने निम्नलिखित चरणों का उपयोग करके इस समस्या को हल किया है

1) हर फाइल को Git के इंडेक्स से निकालें।

git rm --cached -r .

2) सभी नई लाइन एंडिंग लेने के लिए Git इंडेक्स को फिर से लिखें।

git reset --hard

समाधान git साइट https://help.github.com/articles/deal-with-line-endile/ पर वर्णित चरणों का हिस्सा था

Comments

यह काम करता है जब और कुछ नहीं करता है! हमने इसमें और कई अन्य थ्रेड्स में सब कुछ आज़माया है - यह एक बड़ी विकास टीम है इसलिए सभी को एक ही ढलान पर मिल जाना एक बुरा सपना रहा है, लेकिन इससे समस्या हल होती है।

— tkersh

दिलचस्प ... मैंने "git rm --chached <one_specific_file> का उपयोग किया, बजाय सब कुछ हटाने के।" git स्टेटस "ने उस फ़ाइल को डिलीट और अनट्रेक्टेड के रूप में रिपोर्ट किया। फिर" git रीसेट --hard "उस फ़ाइल को और अन्य सभी फ़ाइलों को ठीक करें। के रूप में "परिवर्तन का मंचन नहीं" सूचित किया गया जा रहा है (Git rm उपयोग करने से पहले, मैं हार्ड रीसेट कोई प्रभाव नहीं की कोशिश की) मैं ऐसे रहस्यमय स्रोत नियंत्रण प्रणाली प्यार करता

— joeking

आप जानते हैं, यह आपके सभी कैश को हटा देता है। बड़ी परियोजनाओं में यह बहुत समय बर्बाद कर सकता है।

— ओहर

वह क्रूर है। रेपो डायरेक्टरी को हटाकर और फिर से क्लोनिंग करके आप ऐसा ही कर सकते थे।

— पहुंचें

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

— 3:58

Answer 3

Git उन फ़ाइलों को रीसेट नहीं करेगा जो रिपॉजिटरी में नहीं हैं। तो तुम कर सकते हो:

$ git add .
$ git reset --hard

यह सभी परिवर्तनों को चरणबद्ध करेगा, जिससे गिट उन फाइलों के बारे में जागरूक होंगे, और फिर उन्हें रीसेट कर देंगे।

यदि यह काम नहीं करता है, तो आप अपने परिवर्तनों को छिपाने और गिराने की कोशिश कर सकते हैं:

$ git stash
$ git stash drop

Comments

फाइलों को पहले ही ट्रैक कर लिया गया था। वैसे भी कोशिश की और यह भी काम नहीं करता है। मेरे रेपो के साथ वास्तव में कुछ गलत होना चाहिए, लेकिन मेरे पास कोई सुराग नहीं है। गिट स्टैट बात के लिए, शाहबाज को मेरा जवाब देखें।

— Norswap

जब आप git स्टेटस करते हैं तो क्या हो रहा है?

— यूरीअल्बुकर्क

मैंने एक उपाय के बारे में सोचा। उस कमिट को मिटाने के लिए एक कमिटमेंट और एक इंटरेक्टिव रिबेस बनाएं।

— यूरीअल्बुकर्क

मैंने कोशिश की कि एक बिंदु पर, और यह काम किया, कठिन मैंने बाद में इसे एक और कोशिश दी और मेरे जवाब के संपादन में सामने आए आश्चर्यजनक परिणाम के साथ आया।

— Norswap

@YuriAlbuquerque, Git को POLA की समझ नहीं है । git reset --hard" स्टेजिंग क्षेत्र और मिलान करने के लिए काम करने वाली निर्देशिका दोनों को रीसेट करने" का पूरा बिंदु नहीं है ? यदि किसी फ़ाइल का मंचन नहीं किया जाता है, तो जाहिर है कि हम इसे तब निकालना चाहेंगे जब हम ऐसा करेंगे reset --hard।

— पैसिफायर

Answer 4

यदि आप Windows के लिए Git का उपयोग करते हैं, तो यह आपकी समस्या है

मेरे पास एक ही समस्या है और स्टैश, हार्ड रीसेट, स्वच्छ या यहां तक ​​कि सभी अभी भी बदलावों को पीछे छोड़ रहे थे। क्या समस्या निकला x फ़ाइल मोड जो ठीक से सेट नहीं किया गया था। यह विंडोज़ के लिए गिट के साथ एक "ज्ञात मुद्दा" है। स्थानीय परिवर्तन किसी भी वास्तविक फ़ाइल अंतर के बिना पुराने मोड 100755 नए मोड 100644 के रूप में gitk और git स्थिति में दिखाते हैं।

फिक्स फ़ाइल मोड को अनदेखा करना है:

git config core.filemode false

अधिक जानकारी यहाँ

Comments

यह तब भी काम किया जब तब भी rm -rf *; git checkout HEAD .नहीं किया। ओह!

— फोरम्यूलेटर

मेरे लिए काम किया है, जबकि ड्रॉप / हार्ड रीसेट / आरएम।

— काक्यो

यह मेरे लिए भी काम करता था जब मुझे लिनक्स में गिट रेपो के साथ काम करने में समस्या थी जो मैक पर होस्ट किया गया था

— prmph

मेरे लिए काम किया - बाकी सब कुछ करने की कोशिश की और हाँ पुरानी विधा बनाम नई विधा की समस्या थी (ध्यान दें कि मेरे पास एक अलग संख्या थी लेकिन फाइलें समान हैं)

— ताइहून ए किम

जीवन और समय बचाने वाला।

— योगेश पाटिल

Answer 5

ठीक है, मैंने समस्या हल कर दी है।

ऐसा लगता था कि .gitattributesफ़ाइल, जिसमें:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

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

मेरा फ़िक्स इन फ़ाइलों को हटाने, और अंदर जोड़ने autocrlf = falseके लिए [core]था .git/config।

यह पिछले विन्यास के समान बिल्कुल नहीं है, क्योंकि इसके लिए प्रत्येक देव की आवश्यकता होती है autocrlf = false। मैं एक बेहतर फिक्स ढूंढना चाहता हूं।

संपादित करें:

मैंने कम करने वाली लाइनों पर टिप्पणी की, उन्हें अनियोजित किया और यह काम किया। क्या ... मैं भी नहीं ...!

Comments

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

— स्टीवन सोरिएक

Windows Git पर +1 समान समस्या। पहले से ही था autocrlf = false। मैं अपस्ट्रीम svn रेपो ( git svn fetch/ git merge git-svn) से बदलाव में विलीन हो गया और संशोधित के रूप में चिह्नित 1 फ़ाइल के साथ छोड़ दिया गया। अजीब बात यह है कि मेरे पास यह मुद्दा पहले आया है और मुझे बस एक और शाखा ( -fझंडे के साथ ) की जांच करनी थी , और फिर वापस स्विच करना पड़ा। मैंने ऐसा किया, और यह काम किया, लेकिन जब मैंने एक सुविधा शाखा में स्विच किया, तो "परिवर्तन" वापस आ गया था! उत्तर के नीचे आपका संपादन समाधान था। मेरे मामले में मैंने अपनी .gitattributes फ़ाइल के शीर्ष पर एक पंक्ति में टिप्पणी / असूचीबद्ध की:* text=auto !eol

— हारून ब्लेंकश

उस EDIT ने मेरे लिए भी काम किया: लाइनों को बाहर से टिप्पणी करें .gitattributes, दौड़ें git status, लाइनों को अनकम्प्रेस्ड करें .gitattributes, git statusफिर से चलाएँ

— इग्निटर

ऐसा इसलिए होता है क्योंकि git उन फाइलों को रीसेट कर रहा है, फिर .gitattributesदोबारा लाइन में निर्दिष्ट लाइन को लागू करता है । git diffशायद प्रसिद्ध चलता हरे रंग की लाल / दीवार की दीवार है कि रेखा न खत्म होने वाली मतभेद की खासियत है।

— डैगरूम्स

Answer 6

संभावित कारण # 1 - सामान्यीकरण की समाप्ति रेखा

एक स्थिति जिसमें ऐसा हो सकता है जब प्रश्न में फाइल को लाइन एंडिंग के लिए सही कॉन्फ़िगरेशन के बिना रिपॉजिटरी में चेक किया गया था (1) जिसके परिणामस्वरूप रिपॉजिटरी में फाइल गलत लाइन एंडिंग या मिश्रित लाइन एंडिंग के साथ होती है। पुष्टि करने के लिए, सत्यापित करें कि git diffकेवल लाइन एंडिंग में परिवर्तन दिखाता है (ये डिफ़ॉल्ट रूप से दिखाई नहीं दे सकते हैं, git diff | cat -vगाड़ी के रिटर्न को शाब्दिक ^Mवर्ण के रूप में देखने का प्रयास करें )।

इसके बाद, किसी ने शायद लाइन एंडिंग (2) को सामान्य करने के लिए सेटिंग को जोड़ा .gitattributesया संशोधित किया core.autocrlf। .gitattributesया वैश्विक कॉन्फ़िगरेशन के आधार पर , Git ने आपकी कार्य प्रतिलिपि में स्थानीय परिवर्तन लागू किए हैं जो अनुरोध किए गए सामान्यीकरण को समाप्त करने वाली रेखा को लागू करते हैं। दुर्भाग्य से, किसी कारण से git reset --hardये रेखा सामान्यीकरण में परिवर्तन नहीं करती है।

उपाय

वर्कअराउंड जिसमें लोकल लाइन एंडिंग्स को रीसेट किया जाता है वह समस्या का समाधान नहीं करेगा। हर बार फाइल को "git" द्वारा देखा जाता है, यह सामान्यीकरण की कोशिश करेगा और फिर से करेगा, जिसके परिणामस्वरूप एक ही मुद्दा होगा।

सबसे अच्छा विकल्प यह है कि गिट को सामान्य मिलान लागू करने के लिए इसे रेपो में सभी लाइन एंडिंग को सामान्य करके .gitattributes, और उन परिवर्तनों को करने के लिए लागू किया जाए - देखें कि फ़िल्टर-शाखा के साथ लाइन-एंडिंग को ठीक करने की कोशिश की जा रही है, लेकिन कोई भाग्य नहीं है ।

यदि आप वास्तव में फ़ाइल में परिवर्तनों को मैन्युअल रूप से आज़माना चाहते हैं, तो सबसे आसान समाधान संशोधित फ़ाइलों को मिटाना है, और फिर उन्हें पुनर्स्थापित करने के लिए गिट को बताना है, हालांकि मैं ध्यान देता हूं कि यह समाधान लगातार 100% काम नहीं करता है समय ( चेतावनी: यदि आपकी संशोधित फ़ाइलों में लाइन एंडिंग के अलावा अन्य परिवर्तन नहीं हैं तो इसे न चलाएं !!)

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

ध्यान दें, जब तक आप किसी बिंदु पर रिपॉजिटरी में लाइन एंडिंग्स को सामान्य नहीं करते हैं, तब तक आप इस मुद्दे को जारी रखेंगे।

संभावित कारण # 2 - केस असंवेदनशीलता

दूसरा संभावित कारण विंडोज या मैक ओएस / एक्स पर असंवेदनशीलता है। उदाहरण के लिए, यह कहें कि रिपॉजिटरी में निम्नलिखित की तरह एक पथ मौजूद है:

/foo/bar

अब लिनक्स पर कोई भी फाइल बनाता है /foo/Bar(शायद एक बिल्ड टूल या उस डायरेक्टरी को बनाने के कारण) और धक्का देता है। लिनक्स पर, यह वास्तव में अब दो अलग-अलग निर्देशिकाएं हैं:

/foo/bar/fileA
/foo/Bar/fileA

इस रेपो विंडोज या मैक पर बाहर की जाँच के संशोधित में हो सकता है fileAविंडोज चेक पर कि रीसेट नहीं किया जा सकता है, क्योंकि प्रत्येक रीसेट पर, Git बाहर /foo/bar/fileA, और फिर क्योंकि Windows मामले असंवेदनशील है, की सामग्री को अधिलेखित कर देता है fileAके साथ /foo/Bar/fileAउन्हें में जिसके परिणामस्वरूप की जा रही "संशोधित",।

एक अन्य मामला एक व्यक्तिगत फाइल (एस) हो सकता है जो रेपो में मौजूद होता है, जब एक असंवेदनशील फाइल सिस्टम पर जांच की जाती है, तो वह ओवरलैप हो जाएगा। उदाहरण के लिए:

/foo/bar/fileA
/foo/bar/filea

ऐसी ही अन्य स्थितियां भी हो सकती हैं, जो इस तरह की समस्याएं पैदा कर सकती हैं।

केस असंवेदनशील फाइलसिस्टम पर git को वास्तव में इस स्थिति का पता लगाना चाहिए और एक उपयोगी चेतावनी संदेश दिखाना चाहिए, लेकिन यह वर्तमान में नहीं है (यह भविष्य में बदल सकता है - इस चर्चा और संबंधित प्रस्तावित पैच git.it मेलिंग सूची पर देखें)।

उपाय

इसका समाधान गिट सूचकांक में फाइलों के मामले और विंडोज फाइलसिस्टम पर केस को संरेखण में लाना है। यह या तो लिनक्स पर किया जा सकता है जो चीजों की सही स्थिति दिखाएगा, या विंडोज पर बहुत उपयोगी ओपन सोर्स यूटिलिटी गिट-यूनाइट के साथ । Git-Unite git इंडेक्स में आवश्यक केस परिवर्तन लागू करेगा, जो बाद में रेपो के लिए प्रतिबद्ध हो सकता है।

(1) यह किसी व्यक्ति द्वारा विंडोज का उपयोग करने की सबसे अधिक संभावना थी, बिना किसी .gitattributesफाइल की परिभाषा के, और डिफ़ॉल्ट वैश्विक सेटिंग का उपयोग करना core.autocrlfजिसके लिए है false(देखें (2))।

(२) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Comments

धिक्कार है बेटे, यह सब करने के लिए ले लिया। मुझे पहली पंक्ति के बाद प्रतिबद्ध होना था लेकिन मैं अंत में चेकआउट मास्टर करने में सक्षम था। यह मजेदार नहीं था।

— टिम लेबरमैन

Answer 7

यदि अन्य उत्तर काम नहीं कर रहे हैं, फ़ाइलों को जोड़ने की कोशिश कर रहे हैं, तो रीसेट करना

$ git add -A
$ git reset --hard

मेरे मामले में, यह तब मदद करता है जब खाली फ़ाइलों का एक गुच्छा होता था जो गिट ट्रैक कर रहे थे।

Comments

यह काम। मैंने $ git add .इसके बजाय$ git add -A

— बज़्ने गेरहार्ट-पेडर्सन

Answer 8

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

अधिक जानकारी के लिए: https://stackoverflow.com/a/2016426/67824

Comments

ऐसी फ़ाइलों के नाम खोजने के लिएgit ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d

— डायोमिडिस स्पिनेलिस

Answer 9

आप stashअपने परिवर्तनों को दूर कर सकते हैं, फिर स्टाॅस को गिरा सकते हैं:

git stash
git stash drop

Comments

तुम भी में रुचि हो सकती है इस ।

— शहबाज

Answer 10

इन तरीकों में से कोई भी मेरे लिए काम नहीं करता था, एकमात्र समाधान पूरे रेपो को फिर से बनाना और इसे फिर से क्लोन करना था। इसमें स्टैशिंग, रीसेटिंग, फिर रिसेटिंग जोड़ना, clrf सेटिंग्स, केस सेंसिटिविटी आदि शामिल हैं।

Comments

अद्यतन, यह मेरे घुड़सवार मामले संवेदनशील फाइलसिस्टम वास्तव में संवेदनशील मामला था बाहर कर दिया। मैंने यह तय करने के बाद कि ऊपर वर्णित तकनीकों का उपयोग करके यह समस्या ठीक की गई थी।

— जॉन हंट

Answer 11

क्लीन कमांड चलाएं :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Comments

दुर्भाग्य से यह लाइन अंत से संबंधित मुद्दों को हल नहीं करता है।

— क्रिस्टोफर श्नाइडर

यह केवल एक चीज है जो मेरे मुद्दे को हल करती है, जो भी मेरा मुद्दा था। मेरे पास कोई .gitattributesफाइल नहीं थी और लाइन एंडिंग एक समस्या नहीं थी क्योंकि मैं एक लिनक्स बॉक्स पर हूं और सभी देवता और हमारे सर्वर लिनक्स हैं।

— शमूएल नेफ

Answer 12

अपनी जाँच करें .gitattributes।

मेरे मामले में मेरे पास *.js text eol=lfहै और git विकल्प core.autocrlfथा true।

यह मुझे उस स्थिति में लाता है जब git मेरी फ़ाइलों को समाप्त कर देता है और मुझे इसे ठीक करने के लिए रोकता है और यहां तक git reset --hard HEADकि कुछ भी नहीं करता है।

मैं इसे *.js text eol=lfअपनी टिप्पणी में ठीक कर लेता हूं .gitattributesऔर इसके बाद इसे अनलॉक्ड कर देता हूं ।

ऐसा लगता है कि यह सिर्फ जादू है।

Comments

यह मेरे लिए यह किया गया था, अपने प्रोजेक्ट के उन्नयन शुरू की *.bat text eol=crlfअपने प्रोजेक्ट के लिए।

— सिंह

Answer 13

मैंने इसी तरह के मुद्दे को भी शामिल किया .gitattributes, लेकिन मेरे मामले में GitHub का LFS शामिल था। हालांकि यह बिल्कुल ओपी का परिदृश्य नहीं है, मुझे लगता है कि यह यह वर्णन करने का अवसर प्रदान करता है कि .gitattributesफ़ाइल क्या करती है और क्यों यह "प्रेत" मतभेदों के रूप में अस्थिर परिवर्तनों को जन्म दे सकती है।

मेरे मामले में, पहले से ही एक फाइल मेरे भंडार में थी, जैसे कि समय की शुरुआत से। हाल की एक प्रतिबद्धता में, मैंने एक नए git-lfs trackनियम को एक ऐसे पैटर्न का उपयोग करके जोड़ा, जो थोड़ी बहुत व्यापक थी, और इस प्राचीन फ़ाइल से मेल खाती थी। मुझे पता है कि मैं इस फाइल को बदलना नहीं चाहता था; मुझे पता है कि मैंने फ़ाइल को नहीं बदला है, लेकिन अब यह मेरे अस्थिर परिवर्तनों में था और उस फ़ाइल पर चेकआउट या हार्ड रीसेट की कोई भी राशि इसे ठीक नहीं करने वाली थी। क्यों?

GitHub LFS एक्सटेंशन मुख्य रूप से फ़ाइल के gitमाध्यम से पहुँच प्रदान करने वाले हुक का उपयोग करके काम करता है .gitattributes। आम तौर पर, यह .gitattributesनिर्दिष्ट करने के लिए कि मेल खाने वाली फ़ाइलों को कैसे संसाधित किया जाना चाहिए। ओपी के मामले में, यह लाइन अंत को सामान्य करने से संबंधित था; खदान में, यह था कि एलएफएस को फ़ाइल भंडारण को संभालने दिया जाए या नहीं। या तो मामले में, वास्तव में जो फ़ाइल gitदेखती है वह गणना git diffउस फ़ाइल से मेल नहीं खाती है जो आप फ़ाइल का निरीक्षण करते समय देखते हैं। इसलिए, यदि आप बदलते हैं कि किसी फ़ाइल को उस .gitattributesपैटर्न से कैसे संसाधित किया जाता है जो उससे मेल खाता है, तो यह स्थिति रिपोर्ट में अस्थिर परिवर्तनों के रूप में दिखाई देगा, भले ही वास्तव में फ़ाइल में कोई परिवर्तन न हो।

उस सभी ने कहा, प्रश्न के लिए मेरा "उत्तर" यह है कि यदि .gitattributesफ़ाइल में परिवर्तन कुछ ऐसा है जो आप करना चाहते थे, तो आपको वास्तव में केवल परिवर्तनों को जोड़ना चाहिए और आगे बढ़ना चाहिए। यदि नहीं, तो .gitattributesआप जो करना चाहते हैं उसका बेहतर प्रतिनिधित्व करने के लिए संशोधन करें ।

संदर्भ

1. गिटहब एलएफएस विनिर्देश - एक हश के साथ एक साधारण पाठ फ़ाइल के साथ वस्तुओं में आपकी फ़ाइल को बदलने के लिए वे कैसे कार्य करते हैं cleanऔर smudgeकॉल करते हैं, इसका महान विवरण git।

2. gitattributes दस्तावेज़ीकरण - gitआपके दस्तावेज़ों को संसाधित करने के तरीके को अनुकूलित करने के लिए उपलब्ध सभी विवरण ।

Answer 14

मुझे भी यही समस्या थी। मैंने किया git reset --hard HEADलेकिन फिर भी हर बार जब मैंने किया तो git statusकुछ फाइलों को संशोधित किया गया था।

मेरा समाधान अपेक्षाकृत सरल था। मैंने अभी अपनी IDE को बंद कर दिया (यहाँ यह Xcode था) और अपनी कमांड लाइन को बंद कर दिया (यहाँ यह मेरे Mac OS पर टर्मिनल था) और फिर से कोशिश की और यह काम कर गया।

फिर भी मैं कभी यह नहीं जान पाया कि समस्या क्या है।

Answer 15

मेरा मानना ​​है कि विंडोज़ के लिए git के साथ एक समस्या है जहाँ git अनियमित रूप से चेकआउट पर गलत लाइन एंडिंग लिखता है और केवल वर्कअराउंड कुछ अन्य शाखा को चेकआउट करना है और परिवर्तन को अनदेखा करने के लिए git को बाध्य करना है। फिर उस शाखा की जांच करें जिसे आप वास्तव में काम करना चाहते हैं।

git checkout master -f
git checkout <your branch>

ध्यान रखें कि यह आपके द्वारा जानबूझकर किए गए किसी भी बदलाव को छोड़ देगा, इसलिए ऐसा तभी करें जब आपको चेकआउट के तुरंत बाद यह समस्या हो।

संपादित करें: मैं वास्तव में पहली बार भाग्यशाली हो सकता हूं। यह पता चला है कि शाखाओं को स्विच करने के बाद मुझे फिर से थोड़ा सा मिला। यह पता चला कि शाखाएँ बदलने के बाद फाइल git संशोधित हो रही थी। (जाहिरा तौर पर क्योंकि git लगातार फाइलों को समाप्त करने वाली CRLF लाइन को ठीक से लागू नहीं कर रहा था।)

मैंने विंडोज के लिए नवीनतम git को अपडेट किया और आशा है कि समस्या दूर हो गई है।

Answer 16

इसी तरह का मुद्दा, हालांकि मुझे केवल सतह पर यकीन है। वैसे भी, यह किसी की मदद कर सकता है: मैंने क्या किया (एफटीआईडब्ल्यू, सोर्सट्री में): अनकम्फर्ड फ़ाइल को स्टैक्ड कर दिया, फिर एक हार्ड रीसेट किया।

Answer 17

जैसा कि अन्य जवाबों में कहा गया है, यह समस्या लाइन-एंड ऑटो सही होने के कारण है। मुझे * .svg फ़ाइलों के साथ इस समस्या का सामना करना पड़ा। मैंने अपने प्रोजेक्ट में आइकन के लिए svg फाइल का इस्तेमाल किया।

इस समस्या को हल करने के लिए, मुझे पता है कि svg फ़ाइलों को पाठ के बजाय बाइनरी के रूप में द्विआधारी के रूप में माना जाना चाहिए।

* .svg बाइनरी

Answer 18

एक समान स्थिति में। कई प्रोग्रामर लाइनों के सिरों के सामान विभिन्न एन्कोडिंग करने में सक्षम थे, जो साथ पीड़ा के कई वर्षों (। के परिणामस्वरूप एएसपी एक फाइल में, .js, .css ... नहीं सार)। कुछ समय पहले इनकार कर दिया। रेपो बाईं autorclf = trueऔर के लिए सेटिंग्स safecrlf = warn।

आखिरी समस्या तब उत्पन्न हुई जब अलग-अलग छोरों से संग्रह से सिंक्रनाइज़ किया गया। आर्काइव से कॉपी करने के बाद, गिट स्थिति में नोट के साथ कई फाइलें बदल जाती हैं

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

से टिप्स कैसे Git में काम कर पेड़ लाइन अंत को सामान्य बनाने में? मदद की

git add -u

Answer 19

एक और संभावना है कि मुझे सामना करना पड़ा है कि रिपॉजिटरी में पैकेज में से एक एक अलग हेड के साथ समाप्त हो गया। यदि यहां कोई भी उत्तर मदद नहीं करता है और आप एक git स्टेटस मैसेज का सामना करते हैं, तो आपको भी यही समस्या हो सकती है:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

path/to/packageफ़ोल्डर में जाकर git statusनिम्नलिखित परिणाम प्राप्त करना चाहिए:

HEAD detached at 7515f05

और फिर निम्नलिखित कमांड को समस्या को ठीक करना चाहिए, जहां masterआपकी स्थानीय शाखा द्वारा प्रतिस्थापित किया जाना चाहिए:

git checkout master

और आपको संदेश मिलेगा कि आपकी स्थानीय शाखा दूरस्थ शाखा के पीछे कुछ मात्रा में आवागमन करेगी। git pullऔर आपको जंगल से बाहर होना चाहिए!

Answer 20

किसी कारण के लिए

git add .

काम नहीं किया , लेकिन

$ git add -A

हल निकाला!