यदि Git आपके Mac पर अचानक लगभग हर फ़ाइल को संशोधित के रूप में चिह्नित करता है, तो लाइन एंडिंग रूपांतरण के कारण वर्किंग कॉपी उस संस्करण से भिन्न हो सकती है जिसे Git ट्रैक करता है। फ़ाइलों को बदलने या पुनर्स्थापित करने से पहले रिपॉजिटरी का निरीक्षण करें। फिर macOS-उपयुक्त Git सेटिंग्स का उपयोग करें, और वास्तविक संपादनों की सुरक्षा करने के बाद ही पुन: सामान्यीकरण करें। Git टेक्स्ट को LF एंडिंग्स के साथ संग्रहीत करने की अनुशंसा करता है; इसका macOS मार्गदर्शन core.autocrlf input का उपयोग करता है। GitHub की लाइन-एंडिंग गाइड

लाइन एंडिंग्स हर फ़ाइल को परिवर्तित क्यों दिखा सकती हैं?

लाइन एंडिंग प्रत्येक पंक्ति के अंत को चिह्नित करती है: यूनिक्स-शैली LF में एक वर्ण का उपयोग होता है, जबकि विंडोज-शैली CRLF में कैरिज रिटर्न (CR) और लाइन फीड (LF) का उपयोग होता है। यदि Git या कोई संपादक (editor) पूरी वर्किंग कॉपी में एंडिंग्स बदल देता है, तो Git बड़े पैमाने पर फ़ाइल परिवर्तनों की रिपोर्ट कर सकता है, भले ही टेक्स्ट देखने में बिल्कुल पहले जैसा ही लगे। कॉन्फ़िगरेशन और .gitattributes के आधार पर, Git अपने इंडेक्स में टेक्स्ट को LF पर सामान्यीकृत (normalize) कर सकता है और फ़ाइलों को चेक आउट करते समय विभिन्न एंडिंग्स लागू कर सकता है। Git का gitattributes दस्तावेज़

इसे ठीक करने से पहले रिपॉजिटरी का निरीक्षण करें

टर्मिनल खोलें, रिपॉजिटरी में जाएं, और इसकी स्थिति तथा लाइन-एंडिंग सेटिंग्स की जाँच करें:

git status --short
git config --show-origin --get core.autocrlf
git ls-files --eol

यदि कोई मान सेट नहीं है तो कॉन्फ़िग कमांड शायद कुछ भी प्रिंट न करे। --show-origin यह पहचानने में मदद करता है कि सेटिंग किस कॉन्फ़िग फ़ाइल से ली गई है। git ls-files --eol में, इंडेक्स (i/) और वर्किंग-ट्री (w/) एंडिंग्स की तुलना करें; mixed मिश्रित एंडिंग्स का संकेत देता है। attr/ मान लागू विशेषताओं (attributes) को दिखाता है। Git इस आउटपुट को इंडेक्स, वर्किंग ट्री और लाइन-एंडिंग विशेषताओं के डायग्नोस्टिक के रूप में प्रलेखित करता है। Git का git-ls-files दस्तावेज़

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

macOS के लिए एक समझदारी भरा डिफ़ॉल्ट सेट करें

विभिन्न रिपॉजिटरी में अपने व्यक्तिगत Git उपयोग के लिए, प्रलेखित macOS प्राथमिकता सेट करें:

git config --global core.autocrlf input

input के साथ, Git टेक्स्ट जोड़ते समय CRLF को LF में सामान्यीकृत करता है, चेकआउट पर LF फ़ाइलों को CRLF में बदले बिना। यह सेटिंग हर फ़ाइल की नीति तय नहीं करती है: रिपॉजिटरी एट्रिब्यूट्स फ़ाइल प्रकार के अनुसार व्यवहार निर्दिष्ट कर सकते हैं, और Git के text और eol एट्रिब्यूट्स सामान्यीकरण और चेकआउट एंडिंग्स को नियंत्रित करते हैं। GitHub का प्लेटफ़ॉर्म-विशिष्ट मार्गदर्शन और Git का कॉन्फ़िगरेशन संदर्भ

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

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

परिवर्तनों की समीक्षा करने के बाद ही पुनः सामान्यीकरण (Renormalize) करें

कॉन्फ़िगरेशन या एट्रिब्यूट्स बदलने से यह गारंटी नहीं मिलती है कि मौजूदा फ़ाइलें तुरंत सुसंगत हो जाएंगी। GitHub की प्रलेखित रीफ़्रेश प्रक्रिया पहले बचे हुए काम को सहेजती या कमिट करती है, फिर git add --renormalize . चलाती है और परिणामी स्थिति की समीक्षा करती है। GitHub के रीफ़्रेश निर्देश

अपने संपादनों को सुरक्षित रूप से सहेजने और रिपॉजिटरी नीति तय करने के बाद, सामान्यीकरण को स्टेज करें और बारीकी से निरीक्षण करें कि Git क्या प्रस्तावित करता है:

git add --renormalize .
git status --short
git diff --cached --stat
git diff --cached

स्वचालित रूप से कमिट न करें। स्टेज किए गए diff की समीक्षा करें, विशेष रूप से अनपेक्षित बाइनरी या जनरेट की गई फ़ाइलों की। यदि यह अभी भी ऐसे सामग्री परिवर्तनों को दिखाता है जो आपने नहीं किए थे, तो रुकें और प्रभावित पाथ तथा उनके attr/ मानों का git ls-files --eol के साथ निरीक्षण करें; दोबारा स्टेज करने से पहले एट्रिब्यूट नीति को सही करें। यदि रिपॉजिटरी में पहले असंगत एंडिंग्स संग्रहीत थीं, तो पुन: सामान्यीकरण एक बड़ा वैध diff उत्पन्न कर सकता है, इसलिए आवश्यकता पड़ने पर सहयोगियों के साथ सामान्यीकरण कमिट का समन्वय करें।

यदि फ़ाइलें संशोधित ही बनी रहती हैं

लाइन एंडिंग्स केवल एक संभावित कारण हैं। स्टेज किए गए या अनस्टेज किए गए diffs में वास्तविक अंतरों की तलाश करें, जांचें कि क्या किसी संपादक ने फ़ाइलों को फिर से लिखा है, और फ़ाइल-विशिष्ट फ़िल्टर या एट्रिब्यूट्स का निरीक्षण करें। यदि git ls-files --eol i/lf और w/crlf रिपोर्ट करता है, तो पुष्टि करें कि क्या कोई एट्रिब्यूट या सेटिंग जानबूझकर CRLF का अनुरोध करती है। यदि यह mixed रिपोर्ट करता है, तो पहचानें कि किन फ़ाइलों में मिश्रित एंडिंग्स हैं और सामान्यीकरण से पहले यह देखें कि क्या वे टेक्स्ट हैं। Git के सुरक्षा नियंत्रण अपरिवर्तनीय रूपांतरणों के बारे में चेतावनी दे सकते हैं, लेकिन वे यह नहीं बता सकते कि किसी फ़ाइल को गलत तरीके से टेक्स्ट के रूप में वर्गीकृत किया गया था या नहीं। Git का कॉन्फ़िगरेशन संदर्भ

व्यावहारिक क्रम यह है: संपादनों को सुरक्षित रखें, core.autocrlf और git ls-files --eol का निरीक्षण करें, एक सुसंगत प्रोजेक्ट नीति चुनें, फिर पुन: सामान्यीकृत करें और diff की समीक्षा करें। यह किसी भी वास्तविक सामग्री परिवर्तन पर आपका नियंत्रण बनाए रखते हुए लाइन-एंडिंग के अवांछित शोर को दूर करता है।

स्रोत