फ़ाइल नाम में केवल कैपिटलाइज़ेशन बदलने वाले बदलाव—जैसे कि readme.md से README.md—को Git में रिकॉर्ड कराने के लिए, Terminal में रिपॉजिटरी से git mv चलाएं, फिर git status की मदद से स्टेज किए गए बदलाव की जांच करें। कई Mac पर, डिफ़ॉल्ट APFS फ़ॉर्मेट फ़ाइल नाम के केस को बनाए रखता है लेकिन केस के आधार पर नामों में अंतर नहीं करता, इसलिए Finder में रीनेम करने या सामान्य mv का उपयोग करने से Git इस अंतर को पहचानने में असमर्थ हो सकता है। Apple का उल्लेख है कि APFS को केस-सेंसिटिव (case-sensitive) के रूप में भी फ़ॉर्मेट किया जा सकता है, इसलिए व्यवहार वॉल्यूम पर निर्भर करता है। Apple Developer: Files and directories

git mv के साथ ट्रैक की गई फ़ाइल को रीनेम करें

Terminal में, उस रिपॉजिटरी में जाएं जिसमें वह फ़ाइल मौजूद है। नीचे दिए गए उदाहरण पाथ (paths) को सटीक वर्तमान और इच्छित पाथ से बदलें। यदि किसी नाम में स्पेस या शेल मेटाकैरेक्टर शामिल हैं, तो प्रत्येक पाथ को कोट्स (quotes) में रखना एक अच्छा अभ्यास है।

git mv 'src/readme.md' 'src/README.md'
git status

Git का git mv कमांड वर्किंग-ट्री पाथ को रीनेम करता है और इंडेक्स को अपडेट करता है; बदलाव स्टेज हो जाता है, लेकिन इसे अभी भी कमिट करने की आवश्यकता होती है। Git मैन्युअल के अनुसार सोर्स पाथ का मौजूद होना आवश्यक है और यह बताता है कि इंडेक्स अपडेट सफल मूव (move) के बाद होता है। GitHub का प्रलेखित कमांड-लाइन वर्कफ़्लो भी git mv के बाद git status चेक करने की सलाह देता है। git-mv documentation GitHub Docs: Renaming a file

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

git diff --cached --summary
git diff --cached -- 'src/README.md'

समरी (summary) पाथ परिवर्तन की पुष्टि करने में मदद करती है; दूसरा कमांड आपको उस पाथ के लिए स्टेज की गई सामग्री का निरीक्षण करने की अनुमति देता है। Git कुछ संदर्भों में रीनेम को डिलीट करने और जोड़ने (deletion and addition) के रूप में दिखा सकता है क्योंकि रीनेम का प्रदर्शन फ़ाइल सामग्री और इतिहास से अनुमानित होता है। यहाँ मुख्य जांच यह है कि इंडेक्स में इच्छित पाथ शामिल हो और कोई भी अनपेक्षित स्टेज किए गए बदलाव न हों।

यदि सीधा केवल-केस रीनेम विफल हो जाता है

कुछ केस-इनसेंसिटिव (case-insensitive) वॉल्यूम या Git सेटअप ऐसे सीधे मूव को स्वीकार नहीं करते हैं जिनका सोर्स और डेस्टिनेशन केवल कैपिटलाइज़ेशन में भिन्न होते हैं। एक अलग स्पेलिंग वाले अस्थायी नाम का उपयोग करें, फिर उस अस्थायी पाथ को अंतिम नाम पर ले जाएं:

git mv 'src/readme.md' 'src/readme-case-tmp.md'
git mv 'src/readme-case-tmp.md' 'src/README.md'
git status

अस्थायी पाथ पहले से मौजूद नहीं होना चाहिए। दोनों कमांड के बाद, पुष्टि करें कि स्टेटस केवल इच्छित पुराने-से-नए रीनेम को दिखाता है और स्टेज किए गए डिफ (diff) की जांच करें। यह दो-चरणीय विधि फ़ाइल सिस्टम को अंतर करने के लिए एक मध्यवर्ती नाम देती है, जबकि git mv प्रत्येक सफल चरण पर Git के इंडेक्स को अपडेट करता है। यदि कोई भी कमांड कोई त्रुटि दिखाता है, तो रुकें और पुनः प्रयास करने से पहले git status और डायरेक्टरी की जांच करें; जब तक आपने पुष्टि न कर ली हो कि डेस्टिनेशन को ओवरराइट करना जानबूझकर किया गया है, -f न जोड़ें।

रिपॉजिटरी के केस हैंडलिंग की जांच करें

Git की core.ignoreCase सेटिंग उन फ़ाइल सिस्टमों के लिए समाधान सक्षम करती है जो लेटर केस में अंतर नहीं करते हैं। Git प्रलेखित करता है कि clone और init फ़ाइल सिस्टम की जांच करते हैं और उपयुक्त होने पर यह मान सेट करते हैं; यह यह भी चेतावनी देता है कि इसे बदलने से अप्रत्याशित व्यवहार हो सकता है। आप प्रभावी सेटिंग का निरीक्षण इसके साथ कर सकते हैं: git-config documentation

git config --get core.ignoreCase

यदि कोई मान प्रिंट नहीं होता है, तो इस कमांड को प्रभावी कॉन्फ़िगरेशन में कोई सेटिंग नहीं मिली है। git config core.ignoreCase false को समाधान मानने से बचें: यह Git की मान्यताओं को बदलता है, लेकिन केस-इनसेंसिटिव macOS वॉल्यूम को एक ही डायरेक्टरी में ऐसे दो नाम संग्रहीत करने में सक्षम नहीं बनाता है जो केवल केस में भिन्न हों। इस सेटिंग का प्रलेखित उद्देश्य Git को वास्तविक फ़ाइल सिस्टम व्यवहार के साथ काम करने में मदद करना है, न कि उस व्यवहार को बदलना।

रीनेम की पुष्टि करें, कमिट करें और शेयर करें

कमिट करने से पहले, git status में अंतिम स्पेलिंग सत्यापित करें, स्टेज की गई समरी की जांच करें, और सुनिश्चित करें कि असंबंधित बदलाव शामिल नहीं हैं। जब स्टेज किया गया रीनेम सही हो, तो इसे एक स्पष्ट संदेश के साथ कमिट करें:

git commit -m "Rename readme file to uppercase"

यदि आप कमिट को शेयर करना चाहते हैं, तो अपनी रिपॉजिटरी के सामान्य रिमोट और ब्रांच वर्कफ़्लो का उपयोग करके ब्रांच को पुश करें। रीनेम कमिट में रिकॉर्ड हो जाता है; किसी रिमोट को यह आपके द्वारा पुश करने के बाद ही प्राप्त होगा। केस-सेंसिटिव APFS वॉल्यूम पर, केवल केस वाले नाम अलग हो सकते हैं, जबकि डिफ़ॉल्ट केस-इनसेंसिटिव कॉन्फ़िगरेशन उन्हें एक ही नाम मानता है। विश्वसनीय स्थानीय जांच यही बनी रहती है कि Git का इंडेक्स और स्टेज किया गया स्टेटस इच्छित डेस्टिनेशन पाथ दिखाता है। Apple Support: File system formats available in Disk Utility on Mac

स्रोत