| GIT-GC(1) | Git Manual | GIT-GC(1) |
نام (NAME)
git-gc - پاکسازی فایلهای غیرضروری و بهینهسازی مخزن محلی
خلاصه دستور (SYNOPSIS)
git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
توضیحات (DESCRIPTION)
تعدادی از وظایف نگهداری و مرتبسازی (housekeeping) را در مخزن فعلی اجرا میکند؛ مانند فشردهسازی نسخههای فایل (جهت کاهش فضای دیسک و افزایش کارایی)، حذف اشیاء غیرقابلدسترس که ممکن است از فراخوانیهای قبلی git add ایجاد شده باشند، بستهبندی ارجاعات (refs)، هرس کردن reflog، فرادادههای rerere یا درختهای کاری (working trees) بیاستفاده و کهنه. همچنین ممکن است نمایههای کمکی مانند گراف کامیت (commit-graph) را بهروزرسانی کند.
هنگامی که عملیات متداول پرسلین (دستورات سطح بالای کاربری که شیء جدید ایجاد میکنند) اجرا میشوند، بررسی میکنند که آیا مخزن از زمان آخرین نگهداری رشد چشمگیری داشته است یا خیر، و در صورت لزوم، git gc را به صورت خودکار اجرا میکنند. برای چگونگی غیرفعال کردن این رفتار، پیکربندی gc.auto را در ادامه ببینید.
اجرای دستی git gc تنها زمانی مورد نیاز است که اشیایی بدون اجرای منظم چنین دستورات پرسلینی به مخزن افزوده شوند، یا برای انجام یک بهینهسازی یکباره مخزن، یا مثلاً برای پاکسازی پس از یک درونریزی انبوه غیراستاندارد (mass-import). برای جزئیات بیشتر در مورد موارد درونریزی، بخش «PACKFILE OPTIMIZATION» در git-fast-import(1) را ببینید.
گزینهها (OPTIONS)
--aggressive
--auto
برای چگونگی کارکرد این روش مکاشفهای (heuristic)، گزینه gc.auto در بخش «پیکربندی (CONFIGURATION)» در زیر را ببینید.
به محض آنکه کارهای نگهداری به دلیل عبور از محدودیتهای گزینههای پیکربندی نظیر gc.auto و gc.autoPackLimit آغاز شود، تمامی وظایف دیگر نگهداری (مانند rerere، درختهای کاری، reflog و غیره) نیز اجرا خواهند شد.
--detach, --no-detach
--cruft, --no-cruft
--max-cruft-size=<n>
--expire-to=<dir>
--prune=<date>
--no-prune
--quiet
--force
--keep-largest-pack
بهینهسازی تهاجمی (AGGRESSIVE)
هنگامی که گزینه --aggressive مشخص شود، دستور git-repack(1) با فلگ -f فراخوانی خواهد شد، که به نوبه خود فلگ --no-reuse-delta را به git-pack-objects(1) ارسال میکند. این کار تمام دلتاهای موجود را دور ریخته و آنها را مجدداً محاسبه میکند، که به قیمت صرف زمان بسیار بیشتری در بستهبندی مجدد تمام خواهد شد.
اثرات این بهینهسازی تا حد زیادی ماندگار هستند؛ به عنوان مثال هنگامی که بستهها و اشیاء آزاد درون یک بسته دیگر ادغام میشوند، ممکن است دلتاهای موجود در آن بسته مجدداً استفاده شوند، اما موارد متعددی نیز وجود دارد که در آنها ممکن است دلتایی غیراپتیمال از یک بسته جدیدتر انتخاب شود.
علاوه بر این، ارائه --aggressive گزینههای --depth و --window ارسالی به git-repack(1) را تنظیم میکند. تنظیمات gc.aggressiveDepth و gc.aggressiveWindow را در زیر ببینید. با استفاده از اندازه پنجره بزرگتر، احتمال یافتن دلتاهای بهینهتر بیشتر میشود.
احتمالاً استفاده از این گزینه روی یک مخزن خاص بدون اجرای بنچمارکهای کارایی متناسب، ارزشش را ندارد. این گزینه زمان بسیار بیشتری میبرد و بهینهسازی حاصل در فضا و دلتا ممکن است ارزش این زمان را داشته باشد یا نداشته باشد. عدم استفاده از این گزینه برای اکثر کاربران و مخازن آنها بهترین مصالحه (trade-off) است.
پیکربندی (CONFIGURATION)
تمام موارد زیر این خط در این بخش، به صورت انتخابی از مستندات git-config(1) گنجانده شدهاند. محتوا همان چیزی است که در آنجا یافت میشود:
gc.aggressiveDepth
برای جزئیات بیشتر، مستندات مربوط به گزینه --depth در git-repack(1) را ببینید.
gc.aggressiveWindow
برای جزئیات بیشتر، مستندات گزینه --window در git-repack(1) را ببینید.
gc.auto
تنظیم این مقدار روی صفر نه تنها بستهبندی خودکار بر اساس تعداد اشیاء آزاد را غیرفعال میکند، بلکه سایر روشهای مکاشفهای که git gc --auto برای تشخیص نیاز به کار استفاده میکند (مانند gc.autoPackLimit) را نیز غیرفعال میسازد.
gc.autoPackLimit
متغیر پیکربندی gc.bigPackThreshold را در ادامه ببینید. در صورت استفاده، بر چگونگی عملکرد محدودیت بستهبندی خودکار تأثیر میگذارد.
gc.autoDetach
gc.bigPackThreshold
توجه داشته باشید که اگر تعداد بستههای نگهداشتهشده بیشتر از gc.autoPackLimit باشد، این متغیر پیکربندی نادیده گرفته شده و تمام بستهها به جز بسته پایه مجدداً بستهبندی میشوند. پس از این، تعداد بستهها باید به زیر gc.autoPackLimit برسد و gc.bigPackThreshold دوباره اعمال شود.
اگر مقدار حافظه تخمینزدهشده برای اجرای روان git repack در دسترس نباشد و gc.bigPackThreshold تنظیم نشده باشد، بزرگترین بسته نیز مستثنی خواهد شد (این معادل اجرای git gc با گزینه --keep-largest-pack است).
gc.writeCommitGraph
gc.logExpiry
gc.packRefs
gc.cruftPacks
gc.maxCruftSize
gc.pruneExpire
gc.worktreePruneExpire
gc.reflogExpire, gc.<pattern>.reflogExpire
gc.reflogExpireUnreachable, gc.<pattern>.reflogExpireUnreachable
این نوع مدخلها عموماً در نتیجه استفاده از git commit --amend یا git rebase ایجاد میشوند و کامیتهای قبل از انجام amend یا rebase هستند. از آنجا که این تغییرات بخشی از پروژه فعلی نیستند، بیشتر کاربران مایلند آنها را زودتر منقضی کنند، به همین دلیل پیشفرض آن تهاجمیتر از gc.reflogExpire است.
gc.recentObjectsHook
خروجی باید دقیقاً شامل یک شناسه هگزادسیمال شیء در هر خط و بدون هیچ چیز دیگری باشد. اشیایی که در مخزن یافت نشوند نادیده گرفته میشوند. چندین قلاب (hook) پشتیبانی میشوند، اما همه آنها باید با موفقیت به پایان برسند، در غیر این صورت عملیات (تولید بسته باطله یا باز کردن اشیاء غیرقابل دسترس) متوقف خواهد شد.
gc.repackFilter
gc.repackFilterTo
gc.rerereResolved
gc.rerereUnresolved
نکات (NOTES)
دستور git gc تلاش فراوانی میکند تا اشیایی را که در هر کجای مخزن شما ارجاع داده شدهاند حذف نکند. بهویژه، نه تنها اشیاء ارجاعشده توسط شاخهها و برچسبهای فعلی شما را نگه میدارد، بلکه اشیاء ارجاعشده توسط نمایه (index)، شاخههای ردیابی از راه دور (remote-tracking branches)، لاگهای ارجاع یا reflogs (که ممکن است به کامیتهایی در شاخههایی که بعداً بازنویسی یا اصلاح شدهاند ارجاع دهند) و هر چیز دیگری در فضای نام refs/* را نیز حفظ میکند. توجه داشته باشید یادداشتی (از نوع ایجادشده با git notes) که به یک شیء پیوست شده است، نقشی در زنده نگه داشتن آن شیء ایفا نمیکند. اگر انتظار دارید برخی از اشیاء حذف شوند اما نشدهاند، تمام آن مکانها را بررسی کنید و تصمیم بگیرید که آیا در مورد شما حذف آن ارجاعات منطقی است یا خیر.
از سوی دیگر، هنگامی که git gc همزمان با فرآیند دیگری اجرا میشود، این خطر وجود دارد که شیئی را حذف کند که فرآیند دیگر از آن استفاده میکند اما هنوز ارجاعی به آن ایجاد نکرده است. این امر ممکن است باعث شکست فرآیند دیگر شود یا اگر فرآیند دیگر بعداً ارجاعی به شیء حذفشده اضافه کند، موجب خرابی مخزن گردد. گیت دو ویژگی دارد که این مشکل را به طور چشمگیری کاهش میدهد:
با این حال، این ویژگیها راهحل کاملی نیستند، بنابراین کاربرانی که دستورات را به صورت همزمان اجرا میکنند، باید مقداری از خطر خرابی (که در عمل کم به نظر میرسد) را بپذیرند.
قلابها (HOOKS)
دستور git gc --auto قلاب (hook) با نام pre-auto-gc را اجرا خواهد کرد. برای اطلاعات بیشتر به githooks(5) مراجعه کنید.
همچنین ببینید (SEE ALSO)
گیت (GIT)
بخشی از مجموعه git(1)
| 2026-06-29 | Git 2.55.0 |