যদি গিট হঠাৎ করে আপনার ম্যাকের প্রায় প্রতিটি ফাইলকে পরিবর্তিত হিসেবে চিহ্নিত করে, তবে লাইন এন্ডিং রূপান্তরটি গিট যে সংস্করণ ট্র্যাক করে তার থেকে ওয়ার্কিং কপিকে আলাদা করে দিতে পারে। ফাইল পরিবর্তন বা রিস্টোর করার আগে প্রথমে রিপোজিটরিটি পরিদর্শন করুন। তারপর macOS-উপযোগী গিট সেটিংস ব্যবহার করুন, এবং কেবল আসল সম্পাদনাগুলো সুরক্ষিত করার পরেই রিনরমালাইজ করুন। গিট LF এন্ডিং সহ টেক্সট সংরক্ষণ করার পরামর্শ দেয়; এর macOS নির্দেশনা core.autocrlf input ব্যবহার করে। গিটহাবের লাইন-এন্ডিং নির্দেশিকা

কেন লাইন এন্ডিং প্রতিটি ফাইলকে পরিবর্তিত দেখাতে পারে?

একটি লাইন এন্ডিং প্রতিটি লাইনের সমাপ্তি চিহ্নিত করে: ইউনিক্স-স্টাইলের LF একটি অক্ষর ব্যবহার করে, অন্যদিকে উইন্ডোজ-স্টাইলের CRLF একটি ক্যারেজ রিটার্ন এবং একটি লাইন ফিড ব্যবহার করে। যদি গিট বা কোনো এডিটর ওয়ার্কিং কপি জুড়েই এন্ডিং পরিবর্তন করে, তবে টেক্সট দেখতে একই রকম হলেও গিট ব্যাপকভাবে ফাইল পরিবর্তন রিপোর্ট করতে পারে। কনফিগারেশন এবং .gitattributes-এর ওপর নির্ভর করে গিট তার ইনডেক্সে টেক্সটকে LF-এ নরমালাইজ করতে পারে এবং ফাইলগুলো চেক আউট করার সময় বিভিন্ন এন্ডিং প্রয়োগ করতে পারে। গিটের 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/ মানটি প্রযোজ্য অ্যাট্রিবিউটগুলো দেখায়। গিট এই আউটপুটটিকে ইনডেক্স, ওয়ার্কিং ট্রি এবং লাইন-এন্ডিং অ্যাট্রিবিউটের ডায়াগনস্টিক হিসেবে বর্ণনা করে। গিটের git-ls-files ডকুমেন্টেশন

সামনে এগিয়ে যাওয়ার আগে আসল কোনো সম্পাদনা আছে কিনা তাও পরীক্ষা করুন। আপনি যদি আপনার কাঙ্ক্ষিত পরিবর্তন খুঁজে পান, তবে সেগুলো কমিট করুন অথবা নিরাপদ কোথাও কপি করে রাখুন। লাইন-এন্ডিং ঠিক করার উপায় হিসেবে নির্বিচারে রিস্টোর বা রিসেট ব্যবহার করবেন না: এই কমান্ডগুলো কাজ মুছে ফেলতে পারে। বাইনারি ফাইলগুলোর ক্ষেত্রে বিশেষ সতর্কতা প্রয়োজন কারণ গিট যদি সেগুলোকে টেক্সট হিসেবে গণ্য করে, তবে লাইন-এন্ডিং রূপান্তর ডেটার ক্ষতি করতে পারে। গিটের git-config ডকুমেন্টেশন

macOS-এর জন্য একটি যৌক্তিক ডিফল্ট সেট করুন

রিপোজিটরিজুড়ে আপনার নিজস্ব গিট ব্যবহারের জন্য, ডকুমেন্টে থাকা macOS প্রেফারেন্স সেট করুন:

git config --global core.autocrlf input

input-এর মাধ্যমে, টেক্সট যোগ করার সময় গিট CRLF-কে LF-এ নরমালাইজ করে, তবে চেকআউটের সময় LF ফাইলগুলোকে CRLF-এ রূপান্তর করে না। এই সেটিংটি প্রতিটি ফাইলের নীতি নির্ধারণ করে না: রিপোজিটরি অ্যাট্রিবিউট ফাইলের ধরন অনুযায়ী আচরণ নির্দিষ্ট করতে পারে, এবং গিটের text ও eol অ্যাট্রিবিউট নরমালাইজেশন ও চেকআউট এন্ডিং নিয়ন্ত্রণ করে। গিটহাবের প্ল্যাটফর্ম-নির্দিষ্ট নির্দেশনা এবং গিটের কনফিগারেশন রেফারেন্স

সমস্যাটি যদি কেবল একটি প্রোজেক্টেই সীমাবদ্ধ থাকে, তবে একটি রিপোজিটরির জন্য আপনার গ্লোবাল কনফিগারেশন পরিবর্তন করার চেয়ে সেই প্রোজেক্টের .gitattributes নীতিকে প্রাধান্য দিন। একটি সাধারণ শুরুর বিন্দু হলো * text=auto; নির্দিষ্ট ফরম্যাটগুলোকে LF বা CRLF-এ নির্দিষ্ট করা যেতে পারে, অন্যদিকে বাইনারি ফরম্যাটগুলোকে binary হিসেবে চিহ্নিত করা উচিত। উদাহরণস্বরূপ, শেল স্ক্রিপ্টগুলোর জন্য সাধারণত LF প্রয়োজন হয়, অন্যদিকে কিছু উইন্ডোজ প্রোজেক্ট ফাইলের জন্য CRLF প্রয়োজন হয়। সঠিক প্যাটার্নগুলো রিপোজিটরির টুল এবং সহযোগীদের ওপর নির্ভর করে। গিটের gitattributes উদাহরণসমূহ

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

পরিবর্তনগুলো পর্যালোচনা করার পরেই কেবল রিনরমালাইজ করুন

কনফিগারেশন বা অ্যাট্রিবিউট পরিবর্তন করলেই বিদ্যমান ফাইলগুলো সাথে সাথে সামঞ্জস্যপূর্ণ হয়ে যাবে এমন কোনো নিশ্চয়তা নেই। গিটহাবের ডকুমেন্টেড রিফ্রেশ প্রক্রিয়াটি প্রথমে বাকি থাকা কাজ সেভ বা কমিট করে, তারপর git add --renormalize . চালায় এবং ফলাফল হিসেবে পাওয়া স্ট্যাটাস পর্যালোচনা করে। গিটহাবের রিফ্রেশ নির্দেশাবলী

আপনি নিরাপদে আপনার সম্পাদনাগুলো সেভ করার এবং রিপোজিটরি নীতি নির্ধারণ করার পরে, নরমালাইজেশন স্টেজ করুন এবং গিট ঠিক কী প্রস্তাব করছে তা পর্যবেক্ষণ করুন:

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

স্বয়ংক্রিয়ভাবে কমিট করবেন না। স্টেজ করা ডিফটি পর্যালোচনা করুন, বিশেষ করে অপ্রত্যাশিত বাইনারি বা জেনারেট হওয়া ফাইলগুলো। এটি যদি এখনও এমন বিষয়বস্তু পরিবর্তন দেখায় যা আপনি চাননি, তবে থামুন এবং git ls-files --eol দিয়ে ক্ষতিগ্রস্ত পাথ এবং তাদের attr/ মান পরীক্ষা করুন; পুনরায় স্টেজ করার আগে অ্যাট্রিবিউট নীতি সংশোধন করুন। রিপোজিটরিতে আগে অসঙ্গতিপূর্ণ এন্ডিং সংরক্ষিত থাকলে রিনরমালাইজেশন একটি বড় বৈধ ডিফ তৈরি করতে পারে, তাই প্রয়োজনে সহযোগীদের সাথে নরমালাইজেশন কমিটটি সমন্বয় করুন।

ফাইলগুলো যদি এখনও পরিবর্তিত দেখায়

লাইন এন্ডিং কেবল একটি সম্ভাব্য কারণ। স্টেজ করা বা আনস্টেজ করা ডিফে বাস্তব কোনো পার্থক্য খুঁজুন, কোনো এডিটর ফাইলগুলো পুনরায় লিখেছে কিনা তা পরীক্ষা করুন এবং ফাইল-নির্দিষ্ট ফিল্টার বা অ্যাট্রিবিউটগুলো পরিদর্শন করুন। যদি git ls-files --eol i/lf এবং w/crlf রিপোর্ট করে, তবে কোনো অ্যাট্রিবিউট বা সেটিং ইচ্ছাকৃতভাবে CRLF চাইছে কিনা তা নিশ্চিত করুন। যদি এটি mixed রিপোর্ট করে, তবে নরমালাইজ করার আগে কোন ফাইলগুলোতে মিশ্র এন্ডিং রয়েছে এবং সেগুলো টেক্সট কিনা তা চিহ্নিত করুন। গিটের সেফটি চেকগুলো অপরিবর্তনীয় রূপান্তর সম্পর্কে সতর্ক করতে পারে, কিন্তু কোনো ফাইল ভুলভাবে টেক্সট হিসেবে শ্রেণীবদ্ধ হয়েছে কিনা তা বলতে পারে না। গিটের কনফিগারেশন রেফারেন্স

ব্যবহারিক ক্রমটি হলো: সম্পাদনাগুলো সুরক্ষিত করুন, core.autocrlf এবং git ls-files --eol পরিদর্শন করুন, একটি সুসংগত প্রোজেক্ট নীতি নির্বাচন করুন, তারপর রিনরমালাইজ করুন এবং ডিফ পর্যালোচনা করুন। এটি লাইন-এন্ডিং সংক্রান্ত অপ্রয়োজনীয় ঝামেলা সমাধান করে এবং যেকোনো আসল বিষয়বস্তুর পরিবর্তনের ওপর আপনার নিয়ন্ত্রণ বজায় রাখে।

উৎসসমূহ