Git و عادی سازی انتهای خط

چند ماه پیش، ساعت‌ها تلاش کردم تا در مورد بهترین راه برای مقابله با انتهای خطوط و نحوه تغییر مخزن به استفاده از .gitattributes تصمیم بگیرم. من تازه آن یادداشت های جامع را پیدا کردم و فکر کردم یافتن آنها در اینجا آسان تر از مدفون شدن در یادداشت های من است …

TL; DR

• عادی سازی پایان خط در مورد تبدیل است LF <=> CR+LF، برای سازگاری بین پلتفرم
• .gitattributes فایل امن ترین است git مکانیزمی برای مدیریت عادی سازی انتهای خط
• به روز رسانی تنظیمات عادی سازی مشکل است زیرا git ممکن است تغییرات را در فایل های اصلاح نشده گزارش کند، و کاملاً مشخص نیست که چه اتفاقی می افتد
• برخی از ترفندها برای کمک به درک آنچه اتفاق می افتد و برای رفع مشکلات وجود دارد

انتهای خط و سیستم عامل

وقتی فشار می دهید <Enter> در ویرایشگر متن شما، فایل با کاراکترهای نامرئی که خط جدید را نشان می دهد، اصلاح می شود. این چیز نامرئی معمولاً به دو صورت نشان داده می شود:

• نویسه ASCII LF (با نام مستعار Line Feed)
• نویسه ASCII CR+LF (با نام مستعار Carriage Return + Line Feed)

از لحاظ تاریخی، بیشتر سیستم‌ها به CR+LF نیاز داشتند و سیستم‌های یونیکس در دهه 1980 تصمیم گرفتند که کاراکتر CR را برای ساده‌سازی کارها و صرفه‌جویی در فضای دیسک حذف کنند.

در عمل، ویندوز تنها سیستم عامل مدرنی است که هنوز از انتهای خطوط CRLF استفاده می کند.

هنگامی که در یک تیم توسعه می دهید، در نهایت با افرادی مواجه می شوید که روی ویندوز و سایر سیستم عامل ها کار می کنند و باید این تفاوت را در سیستم کنترل منبع خود مدیریت کنید.

Git’s core.autocrlf

این تنظیمات از طریق git config تعریف شده است. در سطح جهانی یا در هر مخزن اعمال می شود. هنگامی که فعال باشد، نرمال سازی را روی همه فایل هایی که توسط git به عنوان متن شناسایی می شوند اعمال می کند

1. بررسی سبک ویندوز، کامیت سبک یونیکس (core.autocrlf=true)

   • Git هنگام بررسی فایل های متنی، LF را به CRLF تبدیل می کند.
   • هنگام ارسال فایل های متنی، CRLF به LF تبدیل می شود.
   • این مقدار پیش فرضی است که توسط نصب کننده در سیستم های ویندوز فشار داده می شود

2. همانطور که هست پرداخت کنید، سبک یونیکس را انجام دهید (core.autocrlf=input)

   • Git هنگام بررسی فایل های متنی هیچ تبدیلی را انجام نمی دهد.
   • هنگام ارسال فایل های متنی، CRLF به LF تبدیل می شود.
   • برخی از افراد استفاده از آن را هنگام توسعه در سیستم های یونیکس توصیه می کنند

3. همانطور که هست پرداخت کنید، همانطور که هست متعهد شوید (core.autocrlf=false)

   • Git هیچ تبدیلی را هنگام بررسی یا ارسال فایل های متنی انجام نمی دهد.
   • اگر تنظیم تعریف نشده باشد، این مقدار پیش فرض است.

برخی افراد بر این باورند که انجام عادی سازی پایان خط وظیفه git نیست. برای غیرفعال کردن عادی‌سازی git، می‌تواند وسوسه‌انگیز باشد که به «تسویه‌حساب همانطور که انجام می‌شود همانطور که هست» بروید. اما نمی توان آن را به یک مخزن متعهد کرد، بنابراین به تنظیمات ایستگاه کاری توسعه دهنده وابسته است ====> شکننده است.

صرف نظر از آنچه در محلی مردم تعریف شده است core.autocrlf تنظیم، نگهدارنده های مخزن فردی می توانند رفتار را از طریق .gitattributes فایل، که قوی ترین راه برای رفتن است.

.gitattributes

.gitattributes ویژگی هایی را به انواع فایل ها اختصاص می دهد. را text و eol از ویژگی ها برای کنترل فرآیند عادی سازی پایان خط استفاده می شود

مراقب باشید، عادی سازی انتهای خط نباید فعال شود هر دودویی فایل.

به روز رسانی تنظیمات عادی سازی

اگر تنظیمات عادی سازی را تغییر دهید (یا core.autocrlf یا .gitattributes)، روی مخزن محلی خود، مخزن راه دور و ایستگاه های کاری همکارانتان باید کارهایی انجام دهید.

شما همچنین می توانید آن را رها کنید، اما خود را در معرض رفتارهای git عجیب و غریب (فایل های دست نخورده گزارش شده به عنوان تغییر، در میان دیگران) یا مسائل دیگر قرار می دهید.

اولین بازتاب شما این است که به انتهای خطوط در ویرایشگر کد خود نگاه کنید و با دستورات git مختلفی که آنلاین خواهید یافت بازی کنید، اما خیلی سریع می تواند بسیار گیج کننده شود.

تفاوت بین Index و Workspace را مشاهده کنید

در stackoverflow یا وب‌سایت‌های دیگر، «راه‌حل‌ها»/آموزش‌های زیادی خواهید یافت که به شما می‌گویند چه کاری انجام دهید، اما آنها همیشه برخی از موارد لبه را از دست می‌دهند.

نرمال‌سازی Git در فضای کاری اتفاق نمی‌افتد، بلکه در حین انتقال به داخل یا خارج از فهرست اتفاق می‌افتد، بنابراین قبل از اقدام به راهی برای مشاهده پایان‌های خط در فهرست و فضای کاری نیاز دارید.

در اینجا چیزی است که باید بررسی شود تا بفهمید چه اتفاقی می افتد، و بیشتر آموزش ها در مورد آن صحبت نمی کنند:

git ls-files --eol

که می تواند منجر به این نوع خروجی شود:

i/lf    w/crlf  attr/                   Applications/K8S/versions.tf
i/lf    w/lf    attr/text eol=lf        .gitignore
i/-text w/-text attr/                   Services/SMB/hosts-2022-10-20.xlsx
i/lf    w/lf    attr/                   .gitattributes
i/crlf  w/crlf  attr/                   Applications/K8S/ci/backend.tfvars
i/lf    w/crlf  attr/text eol=lf        Legacy/Modules/Keyvault/.gitignore

• i/ به شما می گوید که چگونه فایل در فهرست ذخیره می شود
• w/ به شما می گوید که چگونه فایل در فضای کاری ارائه می شود
• attr/ به شما می گوید که چگونه فایل(های) .gitattributes به git اشاره می کند تا با این فایل مقابله کند.

برای یک توسعه دهنده معمولی ویندوز با استفاده از core.autocrlf=true گزینه (که پیش‌فرض با نصب git در ویندوز اعمال می‌شود)، معمولاً باید ترکیبی از سه نوع اول را دریافت کنید:

• i/lf w/crlf attr/ : فایل توسط git نرمال سازی شده است و از خطوط استاندارد ویندوز استفاده می کند crlf
• i/lf w/lf attr/text eol=lf : فایل توسط git عادی شده و برای استفاده اجرا می شود lf
• i/-text w/-text attr/ : فایل به صورت باینری به صورت خودکار شناسایی می شود و توسط git نرمال سازی نمی شود

اگر در نهایت با ترکیبی از سایر موارد مواجه شدید، ممکن است به این دلیل باشد که شما یا شخصی تغییراتی در آن ایجاد کرده‌اید .gitattributes فایل یا core.autocrlf گزینه.

تعمیر i/crlf w/crlf attr/

این فایل به احتمال زیاد توسط شخصی با استفاده از فشار داده شده است core.autocrlf=false و کار در ویندوز این معمولا باعث می شود git از تغییرات روی فایل های دست نخورده شکایت کند.

رفع استراتژی ها:

https://www.ofcodeandcolor.com/2013/08/29/normalizing-line-endings-in-git-repositories/
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

تعمیر i/lf w/crlf attr/text eol=lf

در این مورد، ایندکس خوب است، اما فضای کاری “شکسته” است.

این فایل احتمالاً قبل از ویژگی بررسی شده است eol=lf مشخص شد.
Git با این کار شما را اذیت نخواهد کرد. اما ممکن است ویرایشگر یا ابزار کد شما در صورت نیاز، شما را باگ کند crlf پایان خط برای برخی از انواع فایل.

مثال ها:

• اگر csproj انتهای خط “اشتباه” داشته باشد، ممکن است استودیوی ویژوال شکایت کند یا انتهای خط نامنسجم را معرفی کند
• terraform شکایت خواهد کرد اگر *.lock.hcl فایل ها دارای انتهای خط اشتباه هستند

راه حل: فایل محلی را حذف کنید و دوباره آن را بررسی کنید

رفع انبوه: خروجی این دستور را به xargs rm وارد کنید، سپس git reset را انجام دهید (با تمام احتیاط های لازم!!!)

git ls-files --eol | grep "i/lf    w/crlf  attr/t" | cut -f2 -d$'\t'

تعمیر i/lf w/lf attr/text eol=crlf

در این مورد، ایندکس خوب است، اما فضای کاری “شکسته” است.

این بار، اگر ابزار یا IDE شما نیاز داشته باشد، ممکن است مشکل ساز باشد lf انتهای خط

راه حل: مانند دیگر وضعیت فضای کاری “شکسته”.