git स्थिति संशोधनों को दिखाती है, git checkout - <file> उन्हें हटाती नहीं है

Question

मैं अपनी कार्यशील प्रतिलिपि में सभी परिवर्तन निकालना चाहूंगा।
रनिंग git statusफ़ाइलों को संशोधित दिखाता है।
इन संशोधनों को हटाने के लिए मुझे कुछ भी नहीं लगता।
उदाहरण के लिए:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Comments

यकीन नहीं है कि git reset --hardयहाँ काम क्यों नहीं किया। नोट: यह git checkout -- `git ls-files -m`फाइलों को रद्द करने के लिए होना चाहिए ( --)

— VonC

यदि आप फ़ाइलों को हटाते हैं और उपयोग करते हैं तो checkout -- <file>यह काम करना चाहिए। परिवर्तन का पता लगाना कुछ स्थितियों में थोड़ा

— अयोग्य

के संभावित डुप्लिकेट कर सकते Git में परिवर्तन छोड़ने के लिए नहीं लग रहे हैं

— Buzz से डी

@ BuZZ-dEE - यह एक डुप्लिकेट है, और पुराने और इसलिए पूर्वता ले जाएगा। लेकिन जब आप जिस प्रश्न से लिंक करते हैं वह अनिवार्य रूप से एक ही होता है, तो नीचे दिया गया उत्तर मैं किसी भी उत्तर की तुलना में बहुत अधिक जानकारीपूर्ण होता हूं, और मेरी समस्या हल कर देता है।

— राबेलामी

एक समाधान नहीं है, लेकिन उबाऊ मामले के लिए एक चाकू चाकू: git update-index --assume-unchagedफ़ाइलों की अपरिवर्तित स्थिति (यहां तक ​​कि बदले हुए लोगों के लिए) को मजबूर करता है

— pdem

Answer 1

इस व्यवहार के कारण कई समस्याएं हो सकती हैं:

सामान्यीकरण को समाप्त करने वाली रेखा

मुझे इस प्रकार की समस्याएं भी हैं। यह स्वचालित रूप से शौचालय को lf में परिवर्तित करने के लिए नीचे आता है। यह आमतौर पर एकल फ़ाइल में मिश्रित लाइन एंडिंग के कारण होता है। फ़ाइल इंडेक्स में सामान्य हो जाती है, लेकिन जब git तब इसे फिर से इसे कार्यशील पेड़ में फ़ाइल के खिलाफ अलग करने के लिए निरूपित करता है, तो परिणाम अलग होता है।

लेकिन अगर आप इसे ठीक करना चाहते हैं, तो आपको core.autocrlf को डिसेबल करना चाहिए , सभी लाइन एंडिंग्स को lf में बदलना चाहिए और फिर इसे फिर से इनेबल करना चाहिए। या आप इसे पूरी तरह से अक्षम कर सकते हैं:

git config --global core.autocrlf false

Core.autocrlf के बजाय , आप .gitattributeफ़ाइलों का उपयोग करने पर भी विचार कर सकते हैं। इस तरह, आप सुनिश्चित कर सकते हैं कि रेपो का उपयोग करने वाले सभी लोग समान सामान्यीकरण नियमों का उपयोग करते हैं, मिश्रित लाइन एंडिंग को रिपॉजिटरी में आने से रोकते हैं।

यदि आप गैर-प्रतिवर्ती सामान्यीकरण किया जाएगा, तो आपको चेतावनी देने के लिए यदि आप चाहते हैं, तो चेतावनी देने के लिए core.safecrlf स्थापित करने पर विचार करें ।

Git manpages यह कहते हैं:

CRLF रूपांतरण डेटा को दूषित करने का एक मामूली मौका देता है। autocrlf = true, CRLF को LF को कमिट के दौरान और LF को CRLF को चेकआउट के दौरान बदल देगा। एक फ़ाइल जिसमें कमिट से पहले LF और CRLF का मिश्रण होता है, उसे git द्वारा दोबारा नहीं बनाया जा सकता है। पाठ फ़ाइलों के लिए यह करना सही बात है: यह लाइन अंत को सही करता है जैसे कि हमारे पास रिपॉजिटरी में केवल एलएफ लाइन अंत है। लेकिन बाइनरी फ़ाइलों के लिए जिन्हें गलती से टेक्स्ट के रूप में वर्गीकृत किया जाता है रूपांतरण डेटा को भ्रष्ट कर सकते हैं।

केस-असंवेदनशील फ़ाइल सिस्टम

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

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

Comments

ठीक है ... तो यह किया है ... अब git स्थिति कोई परिवर्तन नहीं दिखाता है। मैंने आटोक्रॉफ्ट सेटिंग्स पर पढ़ा है, और मैं इसे ठीक से प्राप्त नहीं कर सकता।

— राबेल्माई

अच्छी पकड़! +1। फिर भी मेरे लिए एक और तर्क जो झूठे ( stackoverflow.com/questions/1249932/… ) को स्थापित करने के लिए है ।

— वॉनसी

इसका क्या अर्थ है: "एक फ़ाइल जिसमें LF और CRLF का मिश्रण होता है, उसके पहले कमिट को git द्वारा दोबारा नहीं बनाया जा सकता है।" क्या यह इसलिए है क्योंकि git हमेशा कोर एंडऑटोक्रॉफ्ट सेटिंग के आधार पर लाइन एंडिंग्स को सामान्य करेगा?

— राजबली r

केस सेंसिटिविटी प्रॉब्लम का अधिक सेंस सॉल्यूशन आपके रेपो में कई फोल्डर का न होना है, जिनके नाम केवल केस से अलग होते हैं ।

— ओहद श्नाइडर

उन फ़ाइलों के नाम खोजने के लिए जो केवल पत्र मामले से भिन्न होते हैं, आप चला सकते हैं git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d। ऐसी फ़ाइलों के ऊपरी और निचले दोनों मामलों के नामों को सूचीबद्ध करने के लिएgit ls-tree -r --name-only HEAD | fgrep -i -f <(git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d) | sort -i

— Diomidis Spinellis

Answer 2

मुझे विंडोज पर यह समस्या हो रही थी, लेकिन config --global core.autocrlf falseमैं उपयोग करने के लिए तैयार नहीं था, क्योंकि मैं अपने स्टेश में अन्य निजी शाखाओं और अच्छाइयों को छोड़ने के लिए तैयार नहीं था और एक नए क्लोन के साथ शुरू करता था। मुझे बस कुछ करने की जरूरत है। अभी।

यह मेरे लिए काम कर रहा है, इस विचार पर कि आपने पूरी तरह से अपनी वर्किंग डायरेक्टरी को फिर से लिखने दिया:

git rm --cached -r .
git reset --hard

(ध्यान दें कि मूल प्रश्न में टिप्पणियों में सुझाए गए होने से पहले फ़ाइलों git reset --hardको चलाना न तो बहुत अच्छा था और न ही rmफाइलों पर सादा था reset)

Comments

बदलने के बाद यहां एक और सफलता का core.autocrlfकोई प्रभाव नहीं पड़ा।

— डैनियल बकमास्टर

विंडोज पर भी यह समस्या थी core.autocrlf false। इस जवाब ने काम किया जब कुछ और नहीं होगा।

— केंचिलदा 15

मैंने इस और अन्य सवालों के कई सुझावों की कोशिश की है। यह एकमात्र फिक्स है जिसने मेरे लिए काम किया। मेरे पास कोई विशेषता फ़ाइल नहीं थी और मैंने पहले ही झूठी पर core.autocrlf के साथ शुरुआत कर दी थी।

— भाईदीन

इसने मेरे लिए काम नहीं किया। इसलिए, मैंने इन परिवर्तनों को करने के लिए एक नई शाखा बनाकर और अधिक बदसूरत फैशन किया, क्योंकि वे मेरे लिए वैसे भी बेकार हैं। [java] git checkout -b a-branch-to-bad-crlf-files [/ java] [java] git कमिट -am "कमेटी ऑफ़ द बैड क्रैल्फ़ फाइल्स" [/ java]

— मोहम्मद फ़रीद '

कभी-कभी इस तरह की समस्याएं मुझे वास्तव में एसवीएन याद आती हैं।

— माइक गोडिन

Answer 3

एक और समाधान जो लोगों के लिए काम कर सकता है, क्योंकि मेरे लिए कोई भी पाठ विकल्प काम नहीं करता है:

1. .gitattributesएक पंक्ति के साथ सामग्री को प्रतिस्थापित करें * binary:। यह प्रत्येक फ़ाइल को एक बाइनरी फ़ाइल के रूप में मानने के लिए गिट को बताता है कि यह कुछ भी नहीं कर सकता है।
2. जाँच करें कि अपमानजनक फ़ाइलों के लिए संदेश चला गया है; यदि यह नहीं है तो आप git checkout -- <files>उन्हें रिपॉजिटरी संस्करण में पुनर्स्थापित कर सकते हैं
3. git checkout -- .gitattributes.gitattributesफ़ाइल को उसकी प्रारंभिक स्थिति में पुनर्स्थापित करने के लिए
4. जांचें कि फाइलें अभी भी बदल के रूप में चिह्नित नहीं हैं।

Comments

मैं पिछले कुछ घंटों से फाइलों को वापस करने, खींचने, या छिपाने के लिए सक्षम नहीं होने पर अटक गया हूं। यह मेरे लिए तय था! धन्यवाद! (गिट 1.8.3.1)

— नुस्कूलर

इससे अंत में सफलता पाने से पहले मैंने कई चीजों की कोशिश की। धन्यवाद!

— गेनघी

यह कैसे काम करता है? मुझे लगता है कि .gitattributesमूल में वापस लौटने से एक ही मुद्दा फिर से सामने आएगा, लेकिन अफसोस कि मेरी समस्या अब हल हो गई है। मेरे मामले में अन्य सुझावों में से किसी ने भी काम नहीं किया।

— jdk1.0

@ jdk1.0 मेरी समझ / अनुमान यह है कि दो अलग-अलग तुलना तरीके शामिल हैं। त्रुटि तब होती है जब आपके पास एक अलग रेखा होती है जो कहीं न कहीं समाप्त होती है, और कभी-कभी इसे अनदेखा कर देती है। जब आप पूछते हैं git status, तो पता चलता है कि वे अलग-अलग फाइलें हैं। जब आप पूछते हैं git checkout, तो यह पता चलता है कि उनके पास समान सामग्री है। यह समाधान अस्थायी रूप से गिट को निर्देश दे रहा है कि वह किसी भी संभावित लाइन-एंडिंग चतुराई को अनदेखा करे, और सुनिश्चित करें कि आपकी स्थानीय कॉपी बाइट-फॉर-बाइट के समान है HEAD। एक बार जो हल हो गया है, फिर से शुरू करने के लिए चतुराई की अनुमति देना ठीक है, क्योंकि यह नई त्रुटियों को नहीं जोड़ेगा।

— zebediah49

इससे निपटने में कुछ घंटे बिताए हैं और इस समाधान ने आखिरकार मेरे लिए काम किया है!

— मरियम

Answer 4

भविष्य के लोगों के लिए यह समस्या है: फिलमोड परिवर्तन होने के लक्षण भी एक ही हो सकते हैं। git config core.filemode falseइसे ठीक कर देंगे।

Comments

ऐसा करने के बाद, आपको git checkout .

— मार्टी नील

फिर से चेकआउट किए बिना मेरे लिए काम किया

— फीले

भविष्य के संदर्भ के लिए: यह जानने के लिए कि क्या यह आपकी ज़रूरत है (और अन्य उत्तरों में अन्य फ़िक्सेस नहीं हैं), का उपयोग करें git diffऔर यह इस तरह मोड परिवर्तन के साथ फाइलें दिखाएगा old mode 100755 / new mode 100644।

— पाग

यह मेरे लिए यह निश्चित रूप से कुछ और नहीं होगा के बाद तय की। मुझे सच में नहीं लगता कि लोगों को इंटरनेट पर git cheatsheets और "simple guide" बनाने चाहिए। Git वास्तव में केवल लेने और उपयोग करने के लिए कुछ नहीं है, मुझे लगता है कि यह कुछ ऐसा है जिसे आपको उपयोग करने से पहले समर्पित और औपचारिक प्रशिक्षण और अभ्यास करना होगा।

धन्यवाद, आपने मुझे बहुत सारे आँसू बचाए!

— लुकाज़

Answer 5

यह मुझे पागल कर रहा है, विशेष रूप से कि मैं इसे ऑनलाइन पाए गए किसी भी समाधान के बिना ठीक नहीं कर सकता। यहाँ है कि मैं इसे कैसे हल किया। किसी सहकर्मी का काम होने के बाद से वह यहां क्रेडिट नहीं ले सकता है :)

समस्या का स्रोत: गिट की मेरी प्रारंभिक स्थापना खिड़कियों पर ऑटो लाइन रूपांतरण के बिना थी। इसने GLFW के लिए मेरी प्रारंभिक प्रतिबद्ध को उचित लाइन समाप्त किए बिना किया।

नोट: यह केवल एक स्थानीय समाधान है। रेपो को क्लोन करने वाला अगला लड़का अभी भी इस समस्या से जूझ रहा होगा। एक स्थायी समाधान यहां पाया जा सकता है: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository ।

सेटअप: Glubw परियोजना के साथ Xubuntu 12.04 गिट रेपो

समस्या: glfw फ़ाइलों को रीसेट करने में असमर्थ। मैंने जो भी कोशिश की, वे हमेशा संशोधित के रूप में दिखाते हैं।

हल किया:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Comments

यह टिप्पणी लाइन की सामग्री का उल्लेख करने के लिए सहायक हो सकता है।

— राजबली

दुर्भाग्य से, अधिकांश परियोजनाओं में यह वैकल्पिक .gitattribute फ़ाइल नहीं है

— mchiasson

धन्यवाद। मुझे समझ में नहीं आ रहा है कि यह क्यों आवश्यक है

— diogovk

क्यों? मूल रूप से, यह समाप्त होने वाली रेखा के लिए एक अस्थायी निर्धारण है। नोट में लिंक का पालन करके स्थायी समाधान का उपयोग करें।

— रिचर्ड लैंकेट

Answer 6

मेरे पास एक ही समस्या के साथ एक .bat फ़ाइल थी (इसे अनटैक की गई फ़ाइलों में नहीं निकाला जा सकता था)। git checkout - काम नहीं किया, न ही इस पृष्ठ पर कोई सुझाव दिया। केवल एक चीज जो मेरे लिए काम करती थी:

git stash save --keep-index

और फिर स्टेश को हटाने के लिए:

git stash drop

Comments

इसने मेरे लिए काम किया। ध्यान दें कि --keep-indexमहत्वपूर्ण है।

— user991710

क्यों - प्रशासन-सूचकांक महत्वपूर्ण है?

— चॉयलटन बी। हिगिनबॉटम

Answer 7

एक ही मुद्दा दो बार मिल गया! दोनों बार जब मैंने कुछ बदलाव किए, तो उन्हें वापस करने की कोशिश की। के बाद से मैं बहुत सारी फ़ाइल है कि बदल रहे हैं - लेकिन वे नहीं कर रहे हैं परिवर्तन बदल सकता है! वे बिल्कुल समान हैं।

मुझे लगता है कि मैंने सफलता के बिना उपरोक्त सभी समाधानों की कोशिश की है। कोशिश करने के बाद

git rm --cached -r .
git reset --hard

अब मुझे अपनी रिपॉजिटरी में लगभग सभी फाइलें संशोधित हो गई हैं।

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

परेशान करने की तरह। मैं अब भविष्य में ठोकर खाने से बचूंगा ।।

एकमात्र समाधान एक नया भंडार क्लोन करना और शुरू करना है। (पिछली बार इसे बनाया)

Answer 8

ए करने की कोशिश करो

git checkout -f

यह वर्तमान कार्यशील स्थानीय रेपो में सभी परिवर्तनों को स्पष्ट करना चाहिए

Comments

अच्छा! इसने मेरे लिए काम किया। हालाँकि एक ज़िद्दी मामले के लिए मुझे पहले git checkout -f <another recent branch>तो अपनी शाखा में वापस जाना पड़ाgit checkout -f <branch I'm working on>

— उलट गया अभियंता

Answer 9

मैं केवल अपने रेपो की .gitattributes फ़ाइल (जो परिभाषित * text=autoऔर) को हटाकर इसे ठीक करने में सक्षम था*.c text ) ।

मैं git statusहटाने के बाद भाग गया और संशोधन चले गए। उन्हें वापस जाने के बाद भी वापस नहीं किया गया।

Comments

यह भी अधिक जटिल gitattributes जैसे फिल्टर के साथ काम करता है

— Samizdis

Answer 10

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

इसके अलावा कुछ प्रोग्राम जैसे बैश (लिनक्स पर) के लिए .sh फ़ाइलों को LF समाप्त करना होता है।

यह सुनिश्चित करने के लिए कि ऐसा होता है कि आप गिट्टिवेंज का उपयोग कर सकते हैं। यह रिपॉजिटरी स्तर पर काम करता है, चाहे कोई भी ऑटोक्रेफेल का मूल्य हो।

उदाहरण के लिए आप इस तरह के .gitattributes कर सकते हैं: * पाठ = ऑटो

आप फ़ाइल प्रकार / एक्सटेंशन के प्रति अधिक विशिष्ट हो सकते हैं यदि यह आपके मामले में मायने रखता है।

फिर ऑटोक्रॉफ्ट स्थानीय रूप से विंडोज कार्यक्रमों के लिए लाइन एंडिंग को रूपांतरित कर सकता है।

एक मिश्रित C ​​# / C ++ / Java / Ruby / R, विंडोज / लिनक्स प्रोजेक्ट पर यह अच्छी तरह से काम कर रहा है। अब तक कोई मुद्दा नहीं।

Answer 11

मेरे भी एक ही लक्षण थे लेकिन अलग-अलग चीजों के कारण हुआ है।

मै नही कर सकता था:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

git rm --cached app.jsहटाए गए और अनट्रैक की गई फ़ाइलों के रूप में भी यह संकेत देता है कि मैं app.js. देख सकता हूं लेकिन जब मैंने कोशिश की rm -rf app.jsऔर peform कियाgit status फिर से किया तो यह अभी भी मुझे 'अनट्रैक' में फाइल दिखाता है।

सहकर्मी के साथ कुछ प्रयास करने के बाद हमें पता चला कि यह ग्रंट के कारण हुआ है!

जैसा कि Gruntचालू किया गया है, और क्योंकि app.js को अन्य js फ़ाइलों के जोड़े से उत्पन्न किया गया है, हमें पता चला है कि js फ़ाइलों के साथ प्रत्येक ऑपरेशन के बाद (यह भी app.js) फिर से लिखना app.js।

Answer 12

यह समस्या तब भी हो सकती है जब रेपो में कोई योगदानकर्ता लिनक्स मशीन पर काम करता है, या साइगविन और फाइल की अनुमति वाली विंडो बदल दी जाती है। गिट केवल 755 और 644 के बारे में जानता है।

इस समस्या का उदाहरण और इसके लिए जाँच कैसे करें:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

इससे बचने के लिए, आपको यह सुनिश्चित करना चाहिए कि आप सही तरीके से सेटअप का उपयोग कर रहे हैं

git config --global core.filemode false

Answer 13

यहां बहुत सारे समाधान हैं और मुझे शायद अपने साथ आने से पहले इनमें से कुछ की कोशिश करनी चाहिए थी। वैसे भी यहाँ एक और है ...

हमारा मुद्दा यह था कि हमारे पास एंडलाइन के लिए कोई प्रवर्तन नहीं था और रिपॉजिटरी में डॉस / यूनिक्स का मिश्रण था। इससे भी बदतर यह था कि यह वास्तव में इस स्थिति में एक खुला स्रोत रेपो था, और जिसे हमने कांटा था। निर्णय ओएस रिपॉजिटरी के प्राथमिक स्वामित्व वाले लोगों द्वारा यूनिक्स के सभी एंडलाइन को बदलने के लिए किया गया था और यह प्रतिबद्ध किया गया था जिसमें .gitattributesलाइन एंडिंग को लागू करने के लिए शामिल था।

दुर्भाग्य से ऐसा लगता है कि यहां बताई गई समस्याओं के कारण बहुत कुछ होता है, जहां एक बार DOS-2-Unix से पहले कोड का एक मर्ज किया गया था, फ़ाइलों को हमेशा के लिए बदल दिया जाएगा और वापस नहीं किया जा सकता है।

इसके लिए अपने शोध के दौरान मैं आया था - https://help.github.com/articles/deal-with-line-endings/ - अगर मुझे फिर से इस समस्या का सामना करना पड़ा तो मैं सबसे पहले इसे आज़माकर शुरू करूँगा।

---

मैंने जो किया था यह रहा:

1. मैं शुरू में एक मर्ज कर चुका था, यह महसूस करने से पहले कि मुझे यह समस्या थी और गर्भपात करना था - git reset --hard HEAD( मैं मर्ज संघर्ष में भाग गया। मैं मर्ज को कैसे समाप्त कर सकता हूं? )

2. मैंने VIM में विचाराधीन फाइलों को खोला और यूनिक्स में बदल दिया (:set ff=unix ) में । एक उपकरण जैसे dos2unixपाठ्यक्रम के बजाय इस्तेमाल किया जा सकता है

3. प्रतिबद्ध

4. में विलय master(मास्टर DOS-2-Unix परिवर्तन है)

   git checkout old-code-branch; git merge master

5. सुलझी हुई उलझनें और फाइलें फिर से डॉस थीं इसलिए :set ff=unixवीआईएम में थीं । (नोट मैंने स्थापित किया है https://github.com/itchyny/lightline.vim जिसने मुझे यह देखने की अनुमति दी कि फ़ाइल प्रारूप VIM स्टेटसलाइन पर क्या है)

6. प्रतिबद्ध। सभी छाँटे गए!

Answer 14

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

Answer 15

मैंने सभी परिवर्तनों की सराहना की और फिर किया और पूर्ववत किया। इसने मेरे लिए काम किया

जोड़ देना।

git कमिट-मी "रैंडम कमिट"

git रीसेट - भार HEAD ~ 1

Answer 16

आम तौर पर, अपने सभी संशोधनों और नई फ़ाइलों को खाली करने के लिए GIT में निम्नलिखित 2 कमांड बहुत अच्छी तरह से काम करना चाहिए ( CAREFUL , यह आपके द्वारा बनाई गई सभी नई फ़ाइलों + फ़ोल्डरों को हटा देगा और आपकी सभी संशोधित फ़ाइलों को आपके वर्तमान की स्थिति में पुनर्स्थापित कर देगा) प्रतिबद्ध ):

$ git clean --force -d
$ git checkout -- .

शायद एक बेहतर विकल्प कभी-कभी वैकल्पिक संदेश के साथ "गिट स्टैश पुश" कर रहा है, जैसे:

$ git stash push -m "not sure if i will need this later"

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

एक साइड नोट के रूप में, यदि आप पहले से ही कुछ नई जोड़ी गई फ़ाइलों का मंचन कर चुके हैं और उनसे छुटकारा पाना चाहते हैं, तो यह चाल चलनी चाहिए:

$ git reset --hard

यदि उपरोक्त सभी आपके लिए काम नहीं करते हैं , तो नीचे पढ़ें जो कुछ समय पहले मेरे लिए काम किया था:

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

इसके अलावा, उस बिंदु पर मैं दूसरी शाखा की जांच नहीं कर सकता था, इसलिए मैं अपनी "विकसित" शाखा पर अटक गया था।

यह जो मैंने किया है:

$ git log

मैंने देखा कि मैंने पहले "विकसित" से जो नई शाखा बनाई थी, आज पहले "कमिट" संदेश में दिखाई दे रही थी, जिसका अंत "HEAD -> डेवलपमेंट, ओरिजिन / डेवलपमेंट, ओरिजिन / HEAD, द-ब्रांच-आई-क्रिएट किया गया था। -आज-आज-कल ”।

चूंकि मुझे वास्तव में इसकी आवश्यकता नहीं थी, इसलिए मैंने इसे हटा दिया:

$ git branch -d The-branch-i-created-earlier-today

बदली हुई फाइलें अभी भी दिखाई दे रही थीं, इसलिए मैंने किया:

$ git stash

इससे मेरी समस्या हल हो गई:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

बेशक $ git stash list, $ git stash clearअस्त-व्यस्त परिवर्तन दिखाई देंगे, और चूंकि मेरे पास कुछ भी नहीं था और मुझे अपने किसी भी संघर्ष की आवश्यकता नहीं थी, इसलिए मैंने सभी बाधाओं को हटा दिया।

नोट : मैंने ऐसा करने की कोशिश नहीं की है जो कोई मेरे सामने यहाँ सुझाए:

$ git rm --cached -r .
$ git reset --hard

हो सकता है कि इसने भी काम किया हो, अगली बार जब भी मैं इस समस्या में भाग लूंगा, मैं इसे आज़माऊंगा।

Answer 17

यदि आप एक रिपॉजिटरी क्लोन करते हैं और तुरंत लंबित परिवर्तन देखते हैं, तो रिपॉजिटरी असंगत स्थिति में है। कृपया बाहर * text=autoसे टिप्पणी न करें.gitattributes फ़ाइल । इसे विशेष रूप से वहां रखा गया था क्योंकि भंडार का मालिक एलएफ लाइन अंत के साथ लगातार संग्रहीत सभी फाइलें चाहता है।

जैसा कि HankCa द्वारा कहा गया है, https://help.github.com/articles/deal-with-line-endings/ पर दिए गए निर्देशों का पालन करके समस्या को ठीक करने का तरीका है। आसान बटन:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

फिर रेपो के मालिक को शाखा को मर्ज (या पुल करने का अनुरोध) करें।

Answer 18

इस पृष्ठ पर और कुछ भी काम नहीं किया। यह आखिरकार मेरे लिए काम कर गया। कोई अनियंत्रित, या कमिटेड फ़ाइल नहीं दिखा रहा है।

git add -A
git reset --hard

Answer 19

मेरे लिए समस्या यह थी कि कमांड निष्पादित करते समय विजुअल स्टूडियो खोला गया था

git checkout <file>

विजुअल स्टूडियो को बंद करने के बाद कमांड ने काम किया और मैं अंत में स्टैक से अपना काम लागू कर सकता था। इसलिए उन सभी एप्लिकेशन की जांच करें जो आपके कोड में बदलाव कर सकते हैं, उदाहरण के लिए SourceTree, SmartGit, NotePad, NotePad ++ और अन्य संपादक।

Answer 20

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

git reset --hard
git pull origin
git merge

Answer 21

मैंने इसे संपादित करके .IT / कॉन्फ़िग, जोड़कर हल किया:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

फिर मैं .it / refs / heads / name_branch पर गया और अंतिम कमेंट की आईडी डाल दियाenter code here

Answer 22

मैंने इसे इस तरह हल किया:

1. इच्छित कोड की सामग्री की प्रतिलिपि बनाएँ
2. उस फ़ाइल को हटाएं जो समस्या पैदा कर रही है (वह जिसे आप वापस नहीं कर सकते हैं) अपनी डिस्क से। अब आपको एक ही फ़ाइल के दोनों संस्करणों को हटाए जाने के रूप में चिह्नित करना चाहिए।
3. फ़ाइलों को हटाने के लिए प्रतिबद्ध है।
4. फ़ाइल को फिर से उसी नाम से बनाएँ और सही कोड में पेस्ट करें जिसे आपने चरण 1 में कॉपी किया है
5. नई फ़ाइल के निर्माण के लिए प्रतिबद्ध है।

---

मेरे लिए यही काम आया।

Answer 23

यहाँ एक प्रस्तावित समाधान काम नहीं आया, मुझे पता चला कि फ़ाइल वास्तव में कुछ विशेष पात्रों की एक कड़ी थी:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png