'\" t .\" Title: git-lfs-migrate .\" Author: [see the "AUTHOR(S)" section] .\" Generator: Asciidoctor 2.0.26 .\" Manual: \ \& .\" Source: \ \& .\" Language: Persian .\" .TH "GIT\-LFS\-MIGRATE" "1" "" "\ \&" "\ \&" .ie \n(.g .ds Aq \(aq .el .ds Aq ' .ss \n[.ss] 0 .nh .ad l .de URL \fI\\$2\fP <\\$1>\\$3 .. .als MTO URL .if \n[.g] \{\ . mso www.tmac . am URL . ad l . . . am MTO . ad l . . . LINKSTYLE blue R < > .\} .SH "نام (NAME)" git-lfs-migrate \- مهاجرت تاریخچه به یا از Git LFS .SH "خلاصه دستور (SYNOPSIS)" .sp .nf .fam C \fBgit lfs migrate\fP \fI\fP [\fIoptions\fP] [\fB\-\-\fP] [\fIbranch\fP ...] .fam .fi .SH "توضیحات (DESCRIPTION)" .sp فایل‌ها را در یک مخزن Git به اشاره‌گرهای Git LFS یا برعکس تبدیل می‌کند، یا اندازه‌های فایل‌های Git را بر اساس نوع فایل خلاصه می‌نماید. حالت \f(CRimport\fP فایل‌های Git (یعنی blobها) را به Git LFS تبدیل می‌کند، در حالی که حالت \f(CRexport\fP عمل معکوس آن را انجام می‌دهد، و حالت \f(CRinfo\fP یک خلاصه اطلاعاتی ارائه می‌دهد که می‌تواند در تصمیم‌گیری برای وارد کردن یا خارج کردن فایل‌ها مفید باشد. .sp در همه حالت‌ها، به طور پیش‌فرض \f(CRgit lfs migrate\fP فقط روی شاخه فعلی بررسی‌شده (checked\-out) و فقط روی فایل‌هایی (از هر اندازه و نوعی) کار می‌کند که در کامیت‌هایی اضافه شده‌اند که در هیچ مخزن دوردستی وجود ندارند. گزینه‌های متعددی برای لغو این رفتارهای پیش‌فرض در دسترس هستند. .sp هنگام تبدیل فایل‌ها به یا از Git LFS، دستور \f(CRgit lfs migrate\fP فقط در مخزن محلی و نسخه کاری شما تغییرات ایجاد می‌کند و هرگز روی مخازن دوردست تاثیری نمی‌گذارد. این امر عمدی است زیرا حالت‌های \f(CRimport\fP و \f(CRexport\fP عموماً به این معنا «مخرب» هستند که تاریخچه Git شما را بازنویسی می‌کنند، کامیت‌ها را تغییر می‌دهند و کدهای SHA جدید برای کامیت‌ها تولید می‌نمایند. (استثناء این قاعده، زیرحالت «بدون بازنویسی» \f(CRimport\fP است؛ برای جزئیات به بخش «وارد کردن بدون بازنویسی تاریخچه (IMPORT WITHOUT REWRITING HISTORY)» مراجعه کنید.) .sp بنابراین باید همیشه پیش از استفاده از حالت‌های \f(CRimport\fP یا \f(CRexport\fP کارهای کامیت‌نشده خود را کامیت یا stash کنید، و سپس پیش از ارسال تغییرات به مخازن دوردست، نتیجه مهاجرت را اعتبارسنجی نمایید، برای مثال با اجرای حالت \f(CRinfo\fP و بررسی تاریخچه بازنویسی‌شده کامیت‌ها. .sp هنگامی که از تغییرات رضایت داشتید، باید تاریخچه جدید Git شاخه‌های بازنویسی‌شده را با force\-push به تمام مخازن دوردست خود ارسال کنید. این مرحله‌ای است که باید با دقت انجام شود، زیرا تاریخچه Git را در مخازن دوردست خود دگرگون خواهید کرد. .sp برای بررسی یا تغییر فایل‌ها در شاخه‌هایی غیر از شاخه بررسی‌شده فعلی، می‌توان ارجاعات شاخه را مستقیماً مشخص کرد، یا در یک یا چند گزینه \f(CR\-\-include\-ref\fP ارائه نمود. همچنین می‌توان آن‌ها را با افزودن پیشوند \f(CR^\fP یا مشخص کردن در گزینه‌های \f(CR\-\-exclude\-ref\fP مستثنی کرد. از گزینه \f(CR\-\-everything\fP استفاده کنید تا مشخص شود تمام ارجاعات، از جمله تمام ارجاعات دوردست باید بررسی شوند. برای جزئیات به بخش «شامل کردن و مستثنی کردن ارجاعات (INCLUDE AND EXCLUDE REFERENCES)» مراجعه کنید. .sp برای حالت‌های \f(CRinfo\fP و \f(CRimport\fP، تمام انواع فایل‌ها به طور پیش‌فرض در نظر گرفته می‌شوند؛ در حالی که این ویژگی در حالت \f(CRinfo\fP مفید است، اغلب هنگام وارد کردن (import) مطلوب نیست، بنابراین در این مورد معمولاً باید الگوهای نام فایل (pathspec) یا گزینه \f(CR\-\-fixup\fP مشخص شوند. (حداقل یک pathspec برای شامل کردن در حالت \f(CRexport\fP الزامی است.) الگوهای مسیر را می‌توان با استفاده از گزینه‌های \f(CR\-\-include\fP و \f(CR\-\-exclude\fP (به اختصار \f(CR\-I\fP و \f(CR\-X\fP) تعریف کرد، همان‌طور که در بخش «شامل کردن و مستثنی کردن (INCLUDE AND EXCLUDE)» توضیح داده شده است. .sp از آنجا که استفاده معمول از Git LFS به ردیابی انواع فایل خاص با استفاده از الگوهای نام فایل تعریف‌شده در فایل‌های \f(CR.gitattributes\fP وابسته است، دستور \f(CRgit lfs migrate\fP فایل‌های \f(CR.gitattributes\fP را در صورت لزوم بررسی، ایجاد و اصلاح خواهد کرد. فایل‌های \f(CR.gitattributes\fP همیشه با مجوز پیش‌فرض خواندن/نوشتن (یعنی بدون مجوز اجرا) اختصاص داده می‌شوند. هر پیوند نمادین (symbolic link) با این نام باعث توقف زودهنگام فرآیند مهاجرت خواهد شد. .sp حالت \f(CRimport\fP (به بخش «IMPORT» مراجعه کنید) اشیاء Git از انواع فایل مشخص‌شده (مثلاً با \f(CR\-\-include\fP) را به اشاره‌گرهای Git LFS تبدیل کرده و مدخل‌هایی برای آن انواع فایل به فایل‌های \f(CR.gitattributes\fP اضافه می‌کند، و در صورت عدم وجود این فایل‌ها، آن‌ها را ایجاد می‌نماید. نتیجه باید همانند این باشد که دستورات \f(CRgit lfs track\fP در نقاطی از تاریخچه Git شما متناظر با جایی که هر نوع فایل تبدیل‌شده برای اولین بار ظاهر شده است، اجرا شده باشند. استثناء زمانی است که گزینه \f(CR\-\-fixup\fP داده شود، که در این صورت حالت \f(CRimport\fP فقط فایل‌های موجود \f(CR.gitattributes\fP را بررسی کرده و سپس اشیاء Git را که باید توسط Git LFS ردیابی شوند اما هنوز ردیابی نشده‌اند، تبدیل می‌کند. .sp حالت \f(CRexport\fP (به بخش «EXPORT» مراجعه کنید) به عنوان عملیات معکوس برای حالت \f(CRimport\fP عمل می‌کند، و هر اشاره‌گر Git LFS را که با انواع فایل مشخص‌شده با \f(CR\-\-include\fP مطابقت دارد (که باید حداقل یک بار داده شود) تبدیل می‌نماید. توجه داشته باشید که مدخل‌های \f(CR.gitattributes\fP حذف نخواهند شد، و فایل‌ها نیز حذف نمی‌شوند؛ در عوض، حالت \f(CRexport\fP مدخل‌های «ردیابی نشود» مشابه آنچه توسط دستور \f(CRgit lfs untrack\fP ایجاد می‌شود درج می‌کند. گزینه \f(CR\-\-remote\fP در حالت \f(CRexport\fP برای مشخص کردن مخزن دوردستی که اشیاء Git LFS در صورت عدم وجود در حافظه نهان محلی LFS باید از آن واکشی شوند، در دسترس است؛ در صورت عدم ارائه، \f(CRorigin\fP به طور پیش‌فرض استفاده می‌شود. .sp حالت \f(CRinfo\fP (به بخش «INFO» مراجعه کنید) تعداد کل و اندازه فایل‌ها را در یک مخزن بر اساس نوع فایل (یعنی بر اساس پسوند نام فایل) خلاصه می‌کند. توجه داشته باشید که همانند دو حالت دیگر، به طور پیش‌فرض حالت \f(CRinfo\fP فقط روی شاخه بررسی‌شده فعلی و فقط روی کامیت‌هایی که در هیچ مخزن دوردستی وجود ندارند عمل می‌کند، بنابراین برای دریافت خلاصه‌ای از کل مخزن در تمام شاخه‌ها، از گزینه \f(CR\-\-everything\fP استفاده کنید. اگر اشیاء قبلاً به اشاره‌گرهای Git LFS تبدیل شده باشند، به طور پیش‌فرض اندازه اشیاء ارجاع‌شده جمع‌بندی شده و به طور جداگانه گزارش می‌شود. همچنین می‌توانید با استفاده از \f(CR\-\-pointers=ignore\fP آن‌ها را نادیده بگیرید یا با استفاده از \f(CR\-\-pointers=no\-follow\fP با اشاره‌گرها مانند فایل رفتار کنید. (گزینه دوم مشابه نحوه برخورد با اشاره‌گرهای موجود Git LFS توسط حالت \f(CRinfo\fP در نسخه‌های پیشین Git LFS است). .sp هنگام استفاده از گزینه \f(CR\-\-everything\fP، توجه داشته باشید که این به معنای در نظر گرفتن تمام کامیت‌های در دسترس از تمام ارجاعات (محلی و دوردست) است، اما لزوماً شامل همه انواع فایل نمی‌شود. حالت‌های \f(CRimport\fP و \f(CRinfo\fP به طور پیش‌فرض همه انواع فایل را در نظر می‌گیرند، اگرچه گزینه‌های \f(CR\-\-include\fP و \f(CR\-\-exclude\fP این رفتار را محدود می‌کنند. .sp اگرچه گزینه \f(CR\-\-everything\fP به این معناست که تمام کامیت‌های در دسترس از هر ارجاعی برای مهاجرت در نظر گرفته می‌شوند، اما پس از مهاجرت حتی در صورت مشخص شدن \f(CR\-\-everything\fP فقط ارجاعات محلی به‌روزرسانی خواهند شد. این امر همگام ماندن ارجاعات دوردست با مخزن دوردست مربوطه‌شان را تضمین می‌کند. به عبارت دیگر، \f(CRrefs/heads/foo\fP با گزینه \f(CR\-\-everything\fP به‌روزرسانی خواهد شد، اما \f(CRrefs/remotes/origin/foo\fP به‌روزرسانی نخواهد شد، بنابراین تا زمانی که \f(CRgit push origin foo\fP انجام نشود، با دوردست همگام می‌ماند. پس از بررسی اینکه نتایج یک مهاجرت با \f(CR\-\-everything\fP رضایت‌بخش است، ارسال تمام شاخه‌های محلی به مخازن دوردست با استفاده از گزینه \f(CR\-\-all\fP در دستور \f(CRgit push\fP می‌تواند راحت باشد. .sp مگر اینکه گزینه \f(CR\-\-skip\-fetch\fP داده شده باشد، \f(CRgit lfs migrate\fP همیشه با واکشی فهرست‌های به‌روزشده ارجاعات از تمام مخازن دوردست بازگردانده‌شده توسط \f(CRgit remote\fP آغاز می‌شود، اما همان‌طور که در بالا ذکر شد، پس از اعمال تغییرات در تاریخچه محلی Git در حین تبدیل اشیاء، هرگز آن تغییرات را به طور خودکار به مخازن دوردست شما ارسال نخواهد کرد. .SH "حالت‌ها (MODES)" .sp info .RS 4 نمایش اطلاعات درباره اندازه مخزن. به بخش «INFO» مراجعه کنید. .RE .sp import .RS 4 تبدیل اشیاء Git به اشاره‌گرهای Git LFS. به بخش‌های «IMPORT» و «وارد کردن بدون بازنویسی تاریخچه (IMPORT WITHOUT REWRITING HISTORY)» مراجعه کنید. .RE .sp export .RS 4 تبدیل اشاره‌گرهای Git LFS به اشیاء Git. به بخش «EXPORT» مراجعه کنید. .RE .SH "گزینه‌ها (OPTIONS)" .sp \f(CR\-I \fP, \f(CR\-\-include=\fP .RS 4 به بخش «شامل کردن و مستثنی کردن (INCLUDE AND EXCLUDE)» مراجعه کنید. .RE .sp \f(CR\-X \fP, \f(CR\-\-exclude=\fP .RS 4 به بخش «شامل کردن و مستثنی کردن (INCLUDE AND EXCLUDE)» مراجعه کنید. .RE .sp \f(CR\-\-include\-ref=\fP .RS 4 به بخش «شامل کردن و مستثنی کردن ارجاعات (INCLUDE AND EXCLUDE REFERENCES)» مراجعه کنید. .RE .sp \f(CR\-\-exclude\-ref=\fP .RS 4 به بخش «شامل کردن و مستثنی کردن ارجاعات (INCLUDE AND EXCLUDE REFERENCES)» مراجعه کنید. .RE .sp \f(CR\-\-skip\-fetch\fP .RS 4 فرض می‌کند که مجموعه ارجاعات دوردست شناخته‌شده کامل است، و هنگام تعیین مجموعه کامیت‌های «ارسال‌نشده» برای مهاجرت نباید تازه‌سازی شود. در صورت ترکیب با \f(CR\-\-include\-ref\fP یا \f(CR\-\-exclude\-ref\fP هیچ تاثیری ندارد. .RE .sp \f(CR\-\-everything\fP .RS 4 به بخش «شامل کردن و مستثنی کردن ارجاعات (INCLUDE AND EXCLUDE REFERENCES)» مراجعه کنید. .sp نکته: ارجاعات Git در تمام پلتفرم‌ها در حالت «بسته‌بندی‌شده (packed form)» به حروف کوچک و بزرگ حساس هستند (حساس به بزرگی و کوچکی حروف؛ به \f(CRgit\-pack\-refs(1)\fP مراجعه کنید). در سیستم‌های فایلی که به حروف حساس نیستند، مانند NTFS در ویندوز یا APFS پیش‌فرض در macOS، دستور \f(CRgit\-lfs\-migrate(1)\fP در صورتی که دو یا چند ارجاع فقط از نظر حروف کوچک/بزرگ متفاوت باشند، فقط اولین ارجاع را مهاجرت می‌دهد. .RE .sp \f(CR\-\-yes\fP .RS 4 پاسخ بله را به تمام پرسش‌ها فرض می‌کند و امکان استفاده غیرتعاملی را فراهم می‌سازد. در حال حاضر، تنها پرسش از این دست، پرسشی است که می‌پرسد آیا تغییرات نسخه کاری بازنویسی (نابود) شوند یا خیر. بنابراین، مشخص کردن این گزینه در صورت عدم دقت ممکن است باعث از دست رفتن داده‌ها شود. .RE .sp \f(CR[branch .\|.\|.]\fP .RS 4 فقط مجموعه شاخه‌های فهرست‌شده را مهاجرت می‌دهد. در صورت عدم ارائه، \f(CRgit\-lfs\-migrate(1)\fP شاخه فعلی بررسی‌شده را مهاجرت خواهد داد. .sp ارجاعاتی که با \f(CR^\fP شروع می‌شوند مستثنی خواهند شد، در حالی که شاخه‌هایی که با \f(CR^\fP شروع نمی‌شوند شامل می‌شوند. .sp اگر هر یک از گزینه‌های \f(CR\-\-include\-ref\fP یا \f(CR\-\-exclude\-ref\fP داده شوند، شاخه بررسی‌شده افزوده نمی‌شود، اما شاخه‌هایی که به صراحت داده شده‌اند اضافه خواهند شد. .RE .SS "INFO" .sp حالت \f(CRinfo\fP اندازه‌های اشیاء فایل موجود در تاریخچه Git را خلاصه می‌کند. این حالت از تمام گزینه‌های اصلی \f(CRmigrate\fP و گزینه‌های اضافی زیر پشتیبانی می‌کند: .sp \f(CR\-\-above=\fP .RS 4 فقط فایل‌هایی را شمارش می‌کند که اندازه مجزای آن‌ها بالاتر از اندازه داده‌شده باشد. \f(CRsize\fP می‌تواند به صورت تعداد بایت، یا یک عدد به همراه یک واحد ذخیره‌سازی مشخص شود، مانند "1b"، "20 MB"، "3 TiB" و غیره. .sp اگر در مجموعه‌ای از فایل‌ها با پسوند یکسان، هیچ فایلی وجود نداشته باشد که اندازه مجزای آن بالاتر از حد مشخص‌شده در \f(CR\-\-above\fP باشد، هیچ مدخلی برای آن مجموعه نمایش داده نخواهد شد. .RE .sp \f(CR\-\-top=\fP .RS 4 فقط \f(CRn\fP مدخل برتر را نمایش می‌دهد که بر اساس تعداد کل فایل‌های منطبق با الگوی ارائه‌شده مرتب شده‌اند. پیش‌فرض نمایش فقط ۵ مدخل برتر است. هنگامی که اشیاء موجود Git LFS یافت شوند، علاوه بر \f(CRn\fP مدخل برتر، یک خط جداگانه و اضافی "LFS Objects" در خروجی نمایش داده می‌شود، مگر اینکه از گزینه \f(CR\-\-pointers\fP برای تغییر این رفتار استفاده شود. .RE .sp \f(CR\-\-unit=\fP .RS 4 تعداد بایت‌ها در هر مدخل را در قالب مقداری از واحد ذخیره‌سازی ارائه‌شده قالب‌بندی می‌کند. واحدهای معتبر عبارتند از: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ . sp -1 . IP \(bu 2.3 .\} b، kib، mib، gib، tib، pib \- برای واحدهای ذخیره‌سازی IEC .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ . sp -1 . IP \(bu 2.3 .\} b، kb، mb، gb، tb، pb \- برای واحدهای ذخیره‌سازی SI .sp اگر \f(CR\-\-unit\fP مشخص نشده باشد، بزرگ‌ترین واحدی که بتواند تعداد بایت‌های شمارش‌شده را به صورت یک مقدار عدد صحیح نمایش دهد انتخاب می‌شود. .RE .RE .sp \f(CR\-\-pointers=[follow|no\-follow|ignore]\fP .RS 4 با اشاره‌گرهای موجود Git LFS در تاریخچه بر اساس یکی از سه گزینه رفتار می‌کند. در حالت پیش‌فرض \f(CRfollow\fP، اگر هرگونه اشاره‌گری یافت شود، یک سطر مجزای اضافی "LFS Objects" در خروجی نمایش می‌یابد که تعداد کل و اندازه اشیاء Git LFS ارجاع‌شده توسط اشاره‌گرها را خلاصه می‌کند. در حالت \f(CRignore\fP، اشاره‌گرها نادیده گرفته می‌شوند، در حالی که حالت \f(CRno\-follow\fP رفتار حالت \f(CRinfo\fP در نسخه‌های قدیمی‌تر Git LFS را تکرار می‌کند و با هر اشاره‌گری که بیابد مانند یک فایل معمولی رفتار می‌کند، بنابراین مجموع‌های خروجی فقط شامل محتویات اشاره‌گرها خواهند بود، نه محتویات اشیایی که به آن‌ها اشاره دارند. .RE .sp \f(CR\-\-fixup\fP .RS 4 فیلترهای \f(CR\-\-include\fP و \f(CR\-\-exclude\fP را بر اساس فایل‌های \f(CR.gitattributes\fP در یک مخزن، به ازای هر کامیت استنتاج می‌کند. در عمل، این گزینه هر مسیر فایلی را که طبق فایل(های) \f(CR.gitattributes\fP مخزن باید توسط Git LFS ردیابی شود اما هنوز به اشاره‌گر تبدیل نشده است، شمارش می‌کند. برخلاف خروجی معمول حالت \f(CRinfo\fP، فایل‌های \f(CR.gitattributes\fP گزارش نمی‌شوند. این گزینه با فیلترهای صریح \f(CR\-\-include\fP و \f(CR\-\-exclude\fP و با هر تنظیم \f(CR\-\-pointers\fP به جز \f(CRignore\fP ناسازگار است، از این رو در صورت عدم تعیین صریح، \f(CR\-\-fixup\fP مستلزم \f(CR\-\-pointers=ignore\fP است. .RE .sp قالب خروجی، الگوی نام فایل، اندازه کل اشیاء فایل (به استثنای مواردی که کمتر از آستانه \f(CR\-\-above\fP هستند، در صورتی که تعریف شده باشد) و نسبت تعداد فایل‌های بالاتر از آستانه به تعداد کل فایل‌ها را نشان می‌دهد؛ این نسبت به صورت درصد نیز نمایش داده می‌شود. برای مثال: .sp .if n .RS 4 .nf .fam C *.gif\& 93 MB\& 9480/10504 files(s)\& 90% *.png\& 14 MB\& 1732/1877 files(s)\& 92% .fam .fi .if n .RE .sp به طور پیش‌فرض فقط پنج مدخل اول نمایش داده می‌شوند، اما گزینه \f(CR\-\-top\fP امکان نمایش تعداد بیشتر یا کمتری را در صورت تمایل فراهم می‌سازد. .SS "IMPORT" .sp حالت \f(CRimport\fP اشیاء موجود در تاریخچه Git را به فایل‌های اشاره‌گر ردیابی‌شده و ذخیره‌شده با Git LFS مهاجرت می‌دهد. این حالت از تمام گزینه‌های اصلی \f(CRmigrate\fP و این گزینه‌های اضافی پشتیبانی می‌کند: .sp \f(CR\-\-verbose\fP .RS 4 شناسه oid کامیت و نام فایل‌های مهاجرت‌داده‌شده را در STDOUT چاپ می‌کند. .RE .sp \f(CR\-\-above=\fP .RS 4 فقط فایل‌هایی را مهاجرت می‌دهد که اندازه مجزای آن‌ها بالاتر از اندازه داده‌شده باشد. \f(CRsize\fP می‌تواند به صورت تعداد بایت، یا یک عدد به همراه یک واحد ذخیره‌سازی مشخص شود، مانند "1b"، "20 MB"، "3 TiB" و غیره. از این گزینه نمی‌توان همراه با گزینه‌های \f(CR\-\-include\fP، \f(CR\-\-exclude\fP، و \f(CR\-\-fixup\fP استفاده کرد. .RE .sp \f(CR\-\-object\-map=\fP .RS 4 فایلی با نگاشت هر یک از کامیت‌های بازنویسی‌شده را در \f(CRpath\fP می‌نویسد. قالب فایل CSV با این الگو است: \f(CROLD\-SHA\fP,\f(CRNEW\-SHA\fP .RE .sp \f(CR\-\-no\-rewrite\fP .RS 4 اشیاء را در یک کامیت جدید به Git LFS مهاجرت می‌دهد بدون اینکه تاریخچه Git بازنویسی شود. لطفاً توجه داشته باشید که با استفاده از این گزینه، دستور \f(CRmigrate import\fP انتظار فهرست متفاوتی از آرگومان‌ها را خواهد داشت، گزینه‌های تخصصی در دسترس قرار می‌گیرند، و گزینه‌های اصلی \f(CRmigrate\fP نادیده گرفته می‌شوند. به بخش «وارد کردن بدون بازنویسی تاریخچه (IMPORT WITHOUT REWRITING HISTORY)» مراجعه کنید. .RE .sp \f(CR\-\-fixup\fP .RS 4 فیلترهای \f(CR\-\-include\fP و \f(CR\-\-exclude\fP را بر اساس فایل‌های \f(CR.gitattributes\fP در یک مخزن، به ازای هر کامیت استنتاج می‌کند. در عمل، این گزینه هر مسیر فایلی را که طبق فایل(های) \f(CR.gitattributes\fP مخزن باید توسط Git LFS ردیابی شود اما هنوز اشاره‌گر نیست وارد می‌کند. این گزینه با فیلترهای صریح \f(CR\-\-include\fP و \f(CR\-\-exclude\fP ناسازگار است. .RE .sp اگر \f(CR\-\-no\-rewrite\fP داده نشود و گزینه‌های \f(CR\-\-include\fP یا \f(CR\-\-exclude\fP (به ترتیب \f(CR\-I\fP و \f(CR\-X\fP) داده شوند، فایل \f(CR.gitattributes\fP برای گنجاندن هرگونه الگوی جدید مسیر فایل مطابق با آن فلگ‌ها اصلاح خواهد شد. .sp اگر \f(CR\-\-no\-rewrite\fP داده نشود و هیچ‌یک از این فلگ‌ها داده نشوند، gitattributes به صورت افزایشی اصلاح خواهد شد تا پسوندهای مسیر فایل جدید را همان‌طور که در تاریخچه بازنویسی می‌شوند شامل شود. .SS "وارد کردن بدون بازنویسی تاریخچه (IMPORT WITHOUT REWRITING HISTORY)" .sp حالت \f(CRimport\fP دارای یک زیرحالت ویژه است که با فلگ \f(CR\-\-no\-rewrite\fP فعال می‌شود. این زیرحالت مانند حالت پایه \f(CRimport\fP اشیاء را به اشاره‌گرها مهاجرت می‌دهد، اما این کار را در یک کامیت جدید بدون بازنویسی تاریخچه Git انجام می‌دهد. هنگام استفاده از این زیرحالت، گزینه‌های اصلی \f(CRmigrate\fP مانند \f(CR\-\-include\-ref\fP، و همچنین گزینه‌های حالت اصلی \f(CRimport\fP نادیده گرفته خواهند شد. دستور \f(CRmigrate\fP همچنین فهرست متفاوتی از آرگومان‌ها را می‌پذیرد. در نتیجه این تغییرات، \f(CR\-\-no\-rewrite\fP فقط روی شاخه فعلی کار خواهد کرد \- هر شاخه دیگری که علاقه‌مند به این تغییرات باشد باید کامیت تولیدشده را با خود ادغام کند. .sp زیرحالت \f(CR\-\-no\-rewrite\fP از گزینه‌ها و آرگومان‌های زیر پشتیبانی می‌کند: .sp \f(CR\-m \fP, \f(CR\-\-message=\fP .RS 4 پیام کامیت را برای کامیت تازه‌تولیدشده مشخص می‌کند. .RE .sp [file .\|.\|.] .RS 4 فهرست فایل‌ها برای وارد کردن. این فایل‌ها باید توسط الگوهای مشخص‌شده در gitattributes ردیابی شوند. .RE .sp اگر \f(CR\-\-message\fP داده شود، کامیت جدید با پیام ارائه‌شده ایجاد می‌شود. اگر پیامی ارائه نشود، پیام کامیت بر اساس آرگومان‌های فایل تولید خواهد شد. .SS "EXPORT" .sp حالت \f(CRexport\fP فایل‌های اشاره‌گر Git LFS موجود در تاریخچه Git را از Git LFS خارج کرده و آن‌ها را به فایل‌های شیء متناظرشان تبدیل می‌کند. این حالت از تمام گزینه‌های اصلی \f(CRmigrate\fP و این گزینه‌های اضافی پشتیبانی می‌کند: .sp \f(CR\-\-verbose\fP .RS 4 شناسه oid کامیت و نام فایل‌های مهاجرت‌داده‌شده را در STDOUT چاپ می‌کند. .RE .sp \f(CR\-\-object\-map=\fP .RS 4 فایلی با نگاشت هر یک از کامیت‌های بازنویسی‌شده را در \f(CRpath\fP می‌نویسد. قالب فایل CSV با این الگو است: \f(CROLD\-SHA\fP,\f(CRNEW\-SHA\fP .RE .sp \f(CR\-\-remote=\fP .RS 4 در حین عملیات export اشیاء LFS را از \f(CRgit\-remote\fP مشخص‌شده دانلود می‌کند. در صورت عدم ارائه، به صورت پیش‌فرض \f(CRorigin\fP در نظر گرفته می‌شود. .RE .sp حالت \f(CRexport\fP حداقل به یک الگوی مشخص‌شده با آرگومان \f(CR\-\-include\fP نیاز دارد تا مشخص شود کدام فایل‌ها باید export شوند. فایل‌هایی که با الگوهای \f(CR\-\-include\fP مطابقت دارند از Git LFS حذف خواهند شد، در حالی که فایل‌های منطبق با الگوهای \f(CR\-\-exclude\fP وضعیت Git LFS خود را حفظ می‌کنند. دستور export فایل \f(CR.gitattributes\fP را برای تنظیم یا لغو تنظیم هرگونه الگوی مسیر فایل طبق آن فلگ‌ها اصلاح خواهد کرد. .SH "شامل کردن و مستثنی کردن (INCLUDE AND EXCLUDE)" .sp می‌توانید مشخص کنید که \f(CRgit lfs migrate\fP فقط فایل‌هایی را تبدیل کند که تطبیق مسیر آن‌ها (pathspec) با الگوهای گلوب (glob) گزینه \f(CR\-\-include\fP مطابقت دارد و با الگوهای \f(CR\-\-exclude\fP مطابقت ندارد، تا یا زمان کل مهاجرت کاهش یابد یا فقط بخشی از مخزن شما مهاجرت داده شود. می‌توان چندین الگو را با استفاده از کاما به عنوان جداکننده مشخص کرد. .sp تطبیق الگو به گونه‌ای انجام می‌شود که از نظر عملکردی معادل قالب تطبیق الگو در \f(CR.gitattributes\fP باشد. علاوه بر تطبیق ساده پسوند فایل (مثلاً \f(CR\fB.gif\fP)، الگوها همچنین می‌توانند مسیرهای دایرکتوری را مشخص کنند که در این صورت می‌توان از قالب \f(CRpath/\fP*\fP برای تطبیق بازگشتی استفاده کرد. .sp توجه داشته باشید که این شیوه تطبیق الگو برای گزینه‌های \f(CR\-\-include\fP و \f(CR\-\-exclude\fP مورد استفاده در دستور \f(CRgit lfs migrate\fP، در بین مجموعه‌دستورات \f(CRgit lfs\fP منحصر‌به‌فرد است. سایر دستوراتی که این گزینه‌ها را می‌پذیرند، مانند \f(CRgit lfs ls\-files\fP، در عوض از شکل تطبیق الگوی gitignore(5) استفاده می‌کنند. .SH "شامل کردن و مستثنی کردن ارجاعات (INCLUDE AND EXCLUDE REFERENCES)" .sp می‌توانید مشخص کنید که \f(CRgit lfs migrate\fP فقط فایل‌های اضافه‌شده در کامیت‌های در دسترس از ارجاعات خاص را تبدیل کند، یعنی ارجاعاتی که با استفاده از یک یا چند گزینه \f(CR\-\-include\-ref\fP تعریف شده‌اند، و فایل‌های موجود در کامیت‌های در دسترس از ارجاعات تعریف‌شده در گزینه‌های \f(CR\-\-exclude\-ref\fP را نادیده بگیرد. .sp .if n .RS 4 .nf .fam C D\-\-\-E\-\-\-F /\& \(rs A\-\-\-B\-\-\-\-\-\-C\& refs/heads/my\-feature \(rs\& \(rs \(rs\& refs/heads/main \(rs refs/remotes/origin/main .fam .fi .if n .RE .sp در پیکربندی بالا، کامیت‌های زیر توسط هر ارجاع قابل دسترسی هستند: .sp .if n .RS 4 .nf .fam C refs/heads/main:\& C, B, A refs/heads/my\-feature:\& F, E, D, B, A refs/remote/origin/main:\& A .fam .fi .if n .RE .sp بنابراین، گزینه‌های زیر در \f(CRgit lfs migrate\fP کامیت‌های F، E، D، C، و B را شامل شده، اما کامیت A را مستثنی می‌کنند: .sp .if n .RS 4 .nf .fam C \-\-include\-ref=refs/heads/my\-feature \-\-include\-ref=refs/heads/main \-\-exclude\-ref=refs/remotes/origin/main .fam .fi .if n .RE .sp وجود فلگ \f(CR\-\-everything\fP نشان می‌دهد که تمام کامیت‌های در دسترس از کلیه ارجاعات محلی و دوردست باید مهاجرت داده شوند (اما توجه داشته باشید که خود ارجاعات دوردست به‌روزرسانی نخواهند شد). .SH "مثال‌ها (EXAMPLES)" .SS "مهاجرت کامیت‌های ارسال‌نشده (Migrate unpushed commits)" .sp یک کاربرد متداول برای دستور migrate، تبدیل اشیاء بزرگ Git به LFS پیش از ارسال (push) کامیت‌های شما است. به طور پیش‌فرض، تا زمانی که مخزن non\-bare باشد، فقط کامیت‌هایی را اسکن می‌کند که در هیچ مخزن دوردستی وجود ندارند. .sp ابتدا، \f(CRgit lfs migrate info\fP را اجرا کنید تا انواعی از فایل‌ها را که بیشترین فضا را در مخزن شما اشغال کرده‌اند فهرست کند: .sp .if n .RS 4 .nf .fam C $ git lfs migrate info Fetching remote refs: ..., done Sorting commits: ..., done Examining commits: 100% (1/1), done *.mp3\& 284 MB\& 1/1 files(s)\& 100% *.pdf\& 42 MB\& 8/8 files(s)\& 100% *.psd\& 9.8 MB\& 15/15 files(s)\& 100% *.ipynb 6.9 MB\& 6/6 files(s)\& 100% *.csv\& 5.8 MB\& 2/2 files(s)\& 100% .fam .fi .if n .RE .sp اکنون، می‌توانید \f(CRgit lfs migrate import\fP را برای تبدیل برخی از انواع فایل به LFS اجرا کنید: .sp .if n .RS 4 .nf .fam C $ git lfs migrate import \-\-include="*.mp3,*.psd" Fetching remote refs: ..., done Sorting commits: ..., done Rewriting commits: 100% (1/1), done main\& d2b959babd099fe70da1c1512e2475e8a24de163 \-> 136e706bf1ae79643915c134e17a6c933fd53c61 Updating refs: ..., done .fam .fi .if n .RE .sp اگر پس از تبدیل متوجه شدید که برخی از فایل‌ها در دایرکتوری کاری شما با اشاره‌گرهای Git LFS جایگزین شده‌اند، این امری طبیعی است و نسخه‌های کاری این فایل‌ها را می‌توان با استفاده از \f(CRgit lfs checkout\fP مجدداً با محتویات کامل مورد انتظار پر کرد. .SS "مهاجرت تاریخچه محلی (Migrate local history)" .sp همچنین می‌توانید کل تاریخچه مخزن خود را مهاجرت دهید: .sp .if n .RS 4 .nf .fam C # بررسی فایل‌های بزرگ و اشیاء موجود Git LFS در شاخه اصلی محلی $ git lfs migrate info \-\-include\-ref=main # بررسی فایل‌های بزرگ و اشیاء موجود Git LFS در تمام شاخه‌ها $ git lfs migrate info \-\-everything # بررسی فایل‌های بزرگ در تمام شاخه‌ها با نادیده گرفتن اشیاء موجود Git LFS، # و فهرست کردن ۱۰۰ نتیجه برتر یا کمتر $ git lfs migrate info \-\-everything \-\-pointers=ignore \-\-top=100 .fam .fi .if n .RE .sp همین فلگ‌ها در حالت \f(CRimport\fP نیز کار خواهند کرد: .sp .if n .RS 4 .nf .fam C # تبدیل تمام فایل‌های zip در شاخه اصلی شما $ git lfs migrate import \-\-include\-ref=main \-\-include="*.zip" # تبدیل تمام فایل‌های zip در تمام شاخه‌های محلی $ git lfs migrate import \-\-everything \-\-include="*.zip" # تبدیل تمام فایل‌های بزرگتر از 100K در تمام شاخه‌های محلی $ git lfs migrate import \-\-everything \-\-above=100Kb .fam .fi .if n .RE .sp نکته: این کار نیازمند force\-push به تمام مخازن دوردست موجود Git خواهد بود. استفاده از گزینه \f(CR\-\-all\fP هنگام force\-push در صورتی که ارجاعات محلی متعددی به‌روزرسانی شده باشند (مثلاً پس از import به Git LFS با گزینه \f(CR\-\-everything\fP) می‌تواند راحت باشد. .SS "مهاجرت بدون بازنویسی تاریخچه محلی (با استفاده از migrate import \-\-no\-rewrite)" .sp شما همچنین می‌توانید فایل‌ها را بدون اصلاح تاریخچه موجود مخزن خود مهاجرت دهید. .sp مهاجرت به Git LFS در یک کامیت منفرد و جدید، بدون مشخص کردن پیام کامیت: .sp .if n .RS 4 .nf .fam C $ git lfs track "*.zip" "*.mp3" "*.psd" $ git add .gitattributes $ git commit \-m "add Git LFS attributes" $ git lfs migrate import \-\-no\-rewrite \-\-yes test.zip audios/*.mp3 images/*.psd .fam .fi .if n .RE .sp توجه داشته باشید که الگوهای نام فایل \f(CR\fB.mp3\fP و \f(CR\fP.psd\fP داخل نقل‌قول (کوتیشن) قرار نگرفته‌اند و بنابراین توسط شل (shell) بسط داده می‌شوند، نه توسط دستور \f(CRgit lfs migrate import\fP. برای جزئیات بیشتر به توضیحات پس از مثال بعدی مراجعه کنید. .sp مهاجرت به Git LFS در یک کامیت منفرد و جدید، با یک پیام کامیت مشخص: .sp .if n .RS 4 .nf .fam C $ git lfs track "*.zip" "*.mp3" "*.psd" $ git add .gitattributes $ git commit \-m "add Git LFS attributes" $ git lfs migrate import \-\-no\-rewrite \-\-yes \(rs \-m "Import test.zip, audios/*.mp3, and images/*.psd files" \(rs test.zip audios/*.mp3 images/*.psd .fam .fi .if n .RE .sp توجه داشته باشید که الگوهای نام فایل \f(CR\fB.mp3\fP و \f(CR\fP.psd\fP داخل نقل‌قول قرار نگرفته‌اند و بنابراین توسط شل بسط داده می‌شوند، نه توسط دستور \f(CRgit lfs migrate import\fP. استفاده از علامت نقل‌قول در اطراف چنین الگوهایی با گزینه \f(CR\-\-no\-rewrite\fP پشتیبانی نمی‌شود، زیرا این دستور انتظار فهرستی از فایل‌ها را دارد (احتمالاً بسط داده‌شده توسط شل) و تمام فایل‌های منطبق با یک الگوی نام فایل نقل‌قول‌شده را جستجو نخواهد کرد. .sp البته می‌توان از دستورات اضافی برای یافتن و فهرست کردن تمام فایل‌های منطبق با مجموعه‌ای از الگوها استفاده کرد. در یک محیط سازگار با POSIX مانند لینوکس، macOS یا Git Bash در ویندوز، مثال بالا را می‌توان با دستورات \f(CRfind(1)\fP و \f(CRsed(1)\fP به شرح زیر ترکیب کرد، مشروط بر اینکه فهرست فایل‌های حاصل باعث نشود طول خط فرمان بسط‌یافته از حداکثر مجاز توسط شل فراتر رود: .sp .if n .RS 4 .nf .fam C $ git lfs migrate import \-\-no\-rewrite \-\-yes \(rs $(find . \-name "*.zip" \-o \-name "*.mp3" \-o \-name "*.psd" | sed "s/^\(rs.\(rs///") .fam .fi .if n .RE .sp همچنین توجه داشته باشید که دستور \f(CRgit lfs track\fP به طور پیش‌فرض برچسب‌های زمانی اصلاح را روی هر فایل موجود که با الگوهای نام فایل داده‌شده مطابقت دارد تغییر می‌دهد، به طوری که فایل‌ها در نظر Git به عنوان «تغییریافته» (dirty) ظاهر می‌شوند و در نتیجه کاربر را به تبدیل آن‌ها به فایل‌های Git LFS ترغیب می‌کنند. سپس دستور بعدی \f(CRgit lfs migrate import\fP هشدار می‌دهد که درخت کاری حاوی تغییرات است و از کاربر تایید می‌خواهد تا ادامه دهد، مگر اینکه گزینه \f(CR\-\-yes\fP مشخص شده باشد، همانند مثال‌های بالا. .SS "مهاجرت بدون بازنویسی تاریخچه محلی (با استفاده از add \-\-renormalize)" .sp به عنوان جایگزینی برای استفاده از \f(CRgit lfs migrate import\fP با گزینه \f(CR\-\-no\-rewrite\fP جهت مهاجرت فایل‌ها به Git LFS بدون تغییر تاریخچه موجود مخزن، اگر Git نسخه 2.16.0 یا بالاتر را نصب دارید، می‌توانید از گزینه \f(CR\-\-renormalize\fP در دستور \f(CRgit add\fP برای دستیابی به همین نتیجه استفاده کنید. به عنوان مثال: .sp .if n .RS 4 .nf .fam C $ git lfs track "*.zip" "*.mp3" "*.psd" $ git add .gitattributes $ git add \-\-renormalize . $ git commit \-m "Import all *.zip, *.mp3, and *.psd files to Git LFS" .fam .fi .if n .RE .SS "مهاجرت از Git LFS (Migrate from Git LFS)" .sp اگر دیگر تمایلی به استفاده از Git LFS برای برخی یا تمام فایل‌های خود ندارید، می‌توانید از حالت \f(CRexport\fP برای تبدیل مجدد اشیاء Git LFS به blobهای معمولی Git استفاده کنید. .sp حالت \f(CRexport\fP حداقل به یک pathspec با \f(CR\-\-include\fP نیاز دارد، و هر شیئی را که به صورت محلی یافت نشود از مخزن دوردست Git با نام \f(CRorigin\fP شما یا از مخزن دوردستی که با گزینه \f(CR\-\-remote\fP مشخص می‌کنید دانلود خواهد کرد. .sp .if n .RS 4 .nf .fam C # تبدیل تمام اشیاء Git LFS نوع zip به فایل در شاخه اصلی شما $ git lfs migrate export \-\-include\-ref=main \-\-include="*.zip" # تبدیل تمام اشیاء Git LFS نوع zip به فایل در تمام شاخه‌های محلی، # و واکشی داده‌های اشیایی که به صورت محلی کش نشده‌اند از مخزن دوردست my-remote $ git lfs migrate export \-\-everything \-\-include="*.zip" \-\-remote=my\-remote # تبدیل تمام اشیاء Git LFS به فایل در تمام شاخه‌های محلی $ git lfs migrate export \-\-everything \-\-include="*" .fam .fi .if n .RE .sp نکته: این کار نیازمند force\-push به تمام مخازن دوردست موجود Git خواهد بود. استفاده از گزینه \f(CR\-\-all\fP هنگام force\-push در صورتی که ارجاعات محلی متعددی به‌روزرسانی شده باشند (مثلاً پس از export از Git LFS با گزینه \f(CR\-\-everything\fP) می‌تواند راحت باشد. .SH "همچنین ببینید (SEE ALSO)" .sp git\-lfs\-checkout(1), git\-lfs\-ls\-files(1), git\-lfs\-track(1), git\-lfs\-untrack(1), gitattributes(5), gitignore(5). .sp بخشی از مجموعه git\-lfs(1).