GIT-MAINTENANCE(1) دستورات عمومی کاربر GIT-MAINTENANCE(1)

git-maintenance - اجرای وظایف بهینه‌سازی داده‌های مخزن گیت

git maintenance run [<options>]
git maintenance start [--scheduler=<scheduler>]
git maintenance (stop|register|unregister) [<options>]
git maintenance is-needed [<options>]

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

دستورات گیت که داده‌ها را به مخزن اضافه می‌کنند، مانند git add یا git fetch، برای یک تجربه کاربری پاسخگو بهینه‌سازی شده‌اند. این دستورات زمانی را صرف بهینه‌سازی داده‌های گیت نمی‌کنند، زیرا چنین بهینه‌سازی‌هایی متناسب با اندازه کل مخزن مقیاس‌پذیر هستند، در حالی که این دستورات کاربری هر کدام یک عملیات نسبتاً کوچک را انجام می‌دهند.

دستور git maintenance انعطاف‌پذیری لازم را برای چگونگی بهینه‌سازی مخزن گیت فراهم می‌کند.

run

اجرای یک یا چند وظیفه نگهداری. اگر یک یا چند گزینه --task مشخص شده باشد، آن وظایف به همان ترتیب اجرا می‌شوند. در غیر این صورت، وظایف بر اساس اینکه کدام گزینه‌های پیکربندی maintenance.<task>.enabled برابر با true هستند تعیین می‌شوند. به‌طور پیش‌فرض، فقط maintenance.gc.enabled برابر با true است.

start

شروع اجرای نگهداری روی مخزن جاری. این دستور همان به‌روزرسانی‌های پیکربندی را مانند زیردستور register انجام می‌دهد، سپس زمان‌بند پس‌زمینه را به‌روزرسانی می‌کند تا دستور git maintenance run --scheduled به‌صورت ساعتی اجرا شود.

stop

متوقف کردن زمان‌بندی نگهداری پس‌زمینه. مخزن جاری از فهرست مخازن تحت نگهداری حذف نمی‌شود، تا در صورت راه‌اندازی مجدد نگهداری پس‌زمینه در آینده مشکلی پیش نیاید.

register

مقداردهی اولیه مقادیر پیکربندی گیت به‌گونه‌ای که هرگونه نگهداری زمان‌بندی‌شده روی این مخزن شروع به اجرا کند. این دستور مخزن را به متغیر پیکربندی maintenance.repo در پیکربندی سراسری کاربر جاری، یا پیکربندی مشخص‌شده با گزینه --config-file اضافه می‌کند و برخی از مقادیر توصیه‌شده را برای maintenance.<task>.schedule فعال می‌سازد. وظایفی که فعال می‌شوند برای اجرا در پس‌زمینه بدون اختلال در فرآیندهای پیش‌زمینه ایمن هستند.

زیردستور register همچنین در صورتی که مقدار پیکربندی maintenance.strategy پیش‌تر تنظیم نشده باشد، آن را روی incremental تنظیم می‌کند. راهبرد incremental از زمان‌بندی زیر برای هر وظیفه نگهداری استفاده می‌کند:

•gc: غیرفعال.
•commit-graph: ساعتی.
•prefetch: ساعتی.
•loose-objects: روزانه.
•incremental-repack: روزانه.

دستور git maintenance register همچنین با تنظیم maintenance.auto = false در مخزن جاری، نگهداری پیش‌زمینه را غیرفعال می‌کند. این تنظیم پیکربندی پس از اجرای دستور git maintenance unregister نیز باقی خواهد ماند.

unregister

حذف مخزن جاری از نگهداری پس‌زمینه. این دستور فقط مخزن را از فهرست پیکربندی‌شده حذف می‌کند و مانع از اجرای فرآیندهای نگهداری پس‌زمینه نمی‌شود.

زیردستور unregister اگر مخزن جاری از قبل ثبت نشده باشد، خطایی گزارش خواهد کرد. از گزینه --force استفاده کنید تا حتی زمانی که مخزن جاری ثبت نشده است، وضعیت موفقیت‌آمیز بازگردانده شود.

is-needed

بررسی اینکه آیا نگهداری نیاز به اجرا دارد یا خیر بدون اینکه واقعاً آن را اجرا کند. در صورت نیاز به اجرای نگهداری با کد وضعیت 0 و در غیر این صورت با 1 خارج می‌شود. در حالت ایده‌آل همراه با فلگ --auto استفاده می‌شود.

اگر یک یا چند گزینه --task مشخص شده باشد، آن وظایف به همان ترتیب بررسی می‌شوند. در غیر این صورت، وظایف بر اساس اینکه کدام گزینه‌های پیکربندی maintenance.<task>.enabled برابر با true هستند تعیین می‌شوند. به‌طور پیش‌فرض، فقط maintenance.gc.enabled برابر با true است.

commit-graph

وظیفه commit-graph فایل‌های commit-graph را به صورت افزایشی به‌روزرسانی می‌کند و سپس تأیید می‌کند که داده‌های نوشته‌شده صحیح هستند. نوشتن افزایشی برای اجرا در کنار فرآیندهای همزمان گیت ایمن است، زیرا فایل‌های .graph موجود در فایل قبلی commit-graph-chain را منقضی نمی‌کند. آن‌ها در یک اجرای بعدی بر اساس تاخیر انقضا حذف خواهند شد.

prefetch

وظیفه prefetch دایرکتوری اشیاء را با آخرین اشیاء از تمام ریموت‌های ثبت‌شده به‌روزرسانی می‌کند. برای هر ریموت، یک دستور git fetch اجرا می‌شود. مشخصات ارجاع (refspec) پیکربندی‌شده اصلاح می‌شود تا تمام ارجاعات درخواستی در refs/prefetch/ قرار گیرند. همچنین، تگ‌ها به‌روزرسانی نمی‌شوند.

این کار برای جلوگیری از اختلال در شاخه‌های ردیابی از دور انجام می‌شود. کاربران نهایی انتظار دارند این ارجاعات بدون تغییر باقی بمانند مگر اینکه خودشان یک fetch را آغاز کنند. با این حال، با وظیفه پیش‌واکشی (prefetch)، اشیاء لازم برای تکمیل یک fetch واقعی در آینده از قبل دریافت شده و fetch واقعی را سریع‌تر می‌کند. در حالت ایده‌آل، این عملیات فقط به یک به‌روزرسانی در مجموعه‌ای از شاخه‌های ردیابی از دور بدون هیچ‌گونه انتقال شیء تبدیل خواهد شد.

پیکربندی remote.<name>.skipFetchAll می‌تواند برای مستثنی کردن یک ریموت خاص از پیش‌واکشی استفاده شود.

gc

پاکسازی فایل‌های غیرضروری و بهینه‌سازی مخزن محلی. واژه "GC" مخفف "garbage collection" (جمع‌آوری زباله) است، اما این وظیفه عملیات کوچک بسیاری را انجام می‌دهد. این وظیفه می‌تواند برای مخازن بزرگ پرهزینه باشد، زیرا تمام اشیاء گیت را در یک فایل پک منفرد بسته‌بندی مجدد (repack) می‌کند. همچنین می‌تواند در برخی موقعیت‌ها مخل باشد، زیرا داده‌های قدیمی را حذف می‌کند. برای جزئیات بیشتر در مورد جمع‌آوری زباله در گیت به git-gc(1) مراجعه کنید.

loose-objects

وظیفه loose-objects اشیاء سست را پاکسازی کرده و آن‌ها را در فایل‌های پک قرار می‌دهد. برای جلوگیری از شرایط رقابتی با دستورات همزمان گیت، یک فرآیند دو مرحله‌ای را دنبال می‌کند. ابتدا، هر شیء سستی را که از قبل در یک فایل پک وجود دارد حذف می‌کند؛ فرآیندهای همزمان گیت به‌جای شیء سست، داده‌های شیء را در فایل پک بررسی می‌کنند. دوم، یک فایل پک جدید (که با "loose-" شروع می‌شود) حاوی دسته‌ای از اشیاء سست ایجاد می‌کند.

اندازه دسته به‌طور پیش‌فرض پنجاه هزار شیء است تا از طولانی شدن بیش از حد کار در مخزنی با اشیاء سست زیاد جلوگیری شود. از گزینه پیکربندی maintenance.loose-objects.batchSize برای تنظیم این اندازه استفاده کنید، از جمله مقدار 0 برای حذف محدودیت.

وظیفه gc اشیاء غیرقابل دسترس را به عنوان اشیاء سست می‌نویسد تا در مرحله بعدی پاکسازی شوند، تنها در صورتی که دوباره به یک فایل پک اضافه نشوند؛ به همین دلیل توصیه نمی‌شود که هر دو وظیفه loose-objects و gc را همزمان فعال کنید.

incremental-repack

وظیفه incremental-repack دایرکتوری اشیاء را با استفاده از قابلیت multi-pack-index مجدداً بسته‌بندی می‌کند. برای جلوگیری از شرایط رقابتی با دستورات همزمان گیت، یک فرآیند دو مرحله‌ای را دنبال می‌کند. ابتدا دستور git multi-pack-index expire را فراخوانی می‌کند تا فایل‌های پکی را که توسط فایل multi-pack-index ارجاع داده نشده‌اند حذف کند. دوم، دستور git multi-pack-index repack را فراخوانی می‌کند تا چندین فایل پک کوچک را انتخاب کرده و آن‌ها را در یک فایل پک بزرگتر بسته‌بندی مجدد کند، و سپس ورودی‌های multi-pack-index را که به فایل‌های پک کوچک ارجاع می‌دهند به‌روزرسانی کند تا به فایل پک جدید ارجاع دهند. این کار آن فایل‌های پک کوچک را برای حذف در اجرای بعدی دستور git multi-pack-index expire آماده می‌سازد. انتخاب فایل‌های پک کوچک به گونه‌ای است که اندازه مورد انتظار فایل پک بزرگ حداقل برابر با اندازه دسته باشد؛ به گزینه --batch-size برای زیردستور repack در git-multi-pack-index(1) مراجعه کنید. اندازه پیش‌فرض دسته صفر است، که یک حالت خاص برای تلاش در جهت بسته‌بندی مجدد تمام فایل‌های پک در یک فایل پک واحد است.

pack-refs

وظیفه pack-refs فایل‌های ارجاع سست را جمع‌آوری کرده و آن‌ها را در یک فایل واحد گردآوری می‌کند. این کار عملیاتی را که نیاز به پیمایش در میان ارجاعات متعدد دارند سرعت می‌بخشد. برای اطلاعات بیشتر به git-pack-refs(1) مراجعه کنید.

reflog-expire

وظیفه reflog-expire هرگونه ورودی در reflog را که قدیمی‌تر از آستانه انقضا باشد حذف می‌کند. برای اطلاعات بیشتر به git-reflog(1) مراجعه کنید.

rerere-gc

وظیفه rerere-gc عملیات جمع‌آوری زباله را برای ورودی‌های کهنه در حافظه پنهان rerere فراخوانی می‌کند. برای اطلاعات بیشتر به git-rerere(1) مراجعه کنید.

worktree-prune

وظیفه worktree-prune درخت‌های کاری کهنه یا خراب را حذف می‌کند. برای اطلاعات بیشتر به git-worktree(1) مراجعه کنید.

--auto

هنگامی که با زیردستور run ترکیب شود، وظایف نگهداری را تنها در صورت برآورده شدن آستانه‌های معین اجرا می‌کند. برای مثال، وظیفه gc زمانی اجرا می‌شود که تعداد اشیاء سست از عدد ذخیره‌شده در تنظیم پیکربندی gc.auto فراتر رود، یا زمانی که تعداد فایل‌های پک از تنظیم پیکربندی gc.autoPackLimit بیشتر شود. با گزینه --schedule سازگار نیست. هنگامی که با زیردستور is-needed ترکیب شود، بررسی می‌کند که آیا آستانه‌های مورد نیاز برآورده شده‌اند یا خیر، بدون اینکه واقعاً نگهداری را اجرا کند.

--schedule

هنگامی که با زیردستور run ترکیب شود، وظایف نگهداری را تنها در صورت برآورده شدن شرایط زمانی معین اجرا می‌کند، همان‌طور که توسط مقدار پیکربندی maintenance.<task>.schedule برای هر <task> مشخص شده است. این مقدار پیکربندی تعداد ثانیه‌ها از آخرین باری که آن وظیفه اجرا شده است را طبق مقدار پیکربندی maintenance.<task>.lastRun مشخص می‌کند. وظایفی که آزمایش می‌شوند آن‌هایی هستند که توسط گزینه(های) --task=<task> ارائه شده‌اند یا آن‌هایی که مقدار maintenance.<task>.enabled آن‌ها روی true تنظیم شده است.

--quiet

عدم گزارش پیشرفت یا سایر اطلاعات در stderr.

--task=<task>

اگر این گزینه یک یا چند بار مشخص شود، تنها وظایف مشخص‌شده به همان ترتیب مشخص اجرا می‌شوند. اگر هیچ آرگومان --task=<task> مشخص نشده باشد، تنها وظایفی که maintenance.<task>.enabled آن‌ها روی true پیکربندی شده است در نظر گرفته می‌شوند. برای فهرست مقادیر پذیرفته‌شده <task> به بخش TASKS مراجعه کنید.

--scheduler=auto|crontab|systemd-timer|launchctl|schtasks

هنگامی که با زیردستور start ترکیب شود، زمان‌بند را برای اجرای ساعتی، روزانه و هفتگی دستور git maintenance run مشخص می‌کند. مقادیر ممکن برای <scheduler> عبارتند از auto، crontab (در POSIX)، systemd-timer (در لینوکس)، launchctl (در macOS) و schtasks (در ویندوز). هنگامی که auto مشخص شده باشد، از زمان‌بند مناسب مخصوص پلتفرم استفاده می‌شود؛ در لینوکس، systemd-timer در صورت وجود استفاده می‌شود، در غیر این صورت crontab. پیش‌فرض auto است.

دستور git maintenance برای ساده‌سازی الگوهای نگهداری مخزن طراحی شده است و در عین حال زمان انتظار کاربر را در طول دستورات گیت به حداقل می‌رساند. انواع گزینه‌های پیکربندی برای سفارشی‌سازی این فرآیند در دسترس هستند. گزینه‌های پیش‌فرض نگهداری بر روی عملیاتی تمرکز دارند که به سرعت تکمیل می‌شوند، حتی در مخازن بزرگ.

ممکن است کاربران در مواردی متوجه شوند که وظایف زمان‌بندی‌شده نگهداری به همان تناوبی که در نظر گرفته شده بود اجرا نمی‌شوند. هر دستور git maintenance run یک قفل بر روی پایگاه‌داده اشیاء مخزن ایجاد می‌کند، و این امر مانع از اجرای سایر دستورات همزمان git maintenance run روی همان مخزن می‌شود. بدون این تدبیر امنیتی، فرآیندهای همزمان می‌توانند مخزن را در وضعیتی غیرقابل پیش‌بینی رها کنند.

زمان‌بندی نگهداری پس‌زمینه فرآیندهای git maintenance run را به‌صورت ساعتی اجرا می‌کند. هر اجرا وظایف "hourly" (ساعتی) را اجرا می‌کند. در نیمه‌شب، آن فرآیند وظایف "daily" (روزانه) را نیز اجرا می‌کند. در نیمه‌شب اولین روز هفته، آن فرآیند وظایف "weekly" (هفتگی) را نیز اجرا می‌کند. یک فرآیند واحد بر روی هر مخزن ثبت‌شده تکرار می‌شود و وظایف زمان‌بندی‌شده را برای آن تناوب زمانی انجام می‌دهد. فرآیندها در یک دقیقه تصادفی از هر ساعت برای هر کلاینت زمان‌بندی می‌شوند تا بار ترافیکی که ممکن است چند کلاینت ایجاد کنند (مثلاً ناشی از پیش‌واکشی) پخش شود. بسته به تعداد مخازن ثبت‌شده و اندازه آن‌ها، این فرآیند ممکن است بیش از یک ساعت طول بکشد. در این حالت، چندین دستور git maintenance run ممکن است به‌طور همزمان بر روی یک مخزن اجرا شوند و بر سر قفل پایگاه‌داده اشیاء تداخل ایجاد کنند. این امر منجر به عدم اجرای یکی از دو وظیفه می‌شود.

اگر متوجه شدید که تکمیل برخی از بازه‌های نگهداری بیش از یک ساعت طول می‌کشد، کاهش پیچیدگی وظایف نگهداری خود را مد نظر قرار دهید. برای مثال، وظیفه gc بسیار کندتر از وظیفه incremental-repack است. با این حال، این امر به بهای یک پایگاه‌داده اشیاء کمی بزرگتر تمام می‌شود. انتقال وظایف سنگین‌تر را به تناوب‌های زمانی کمتر مد نظر قرار دهید.

کاربران باتجربه ممکن است زمان‌بندی وظایف نگهداری خود را با استفاده از برنامه‌ای متفاوت از آنچه از طریق git maintenance start و گزینه‌های پیکربندی گیت موجود است در نظر بگیرند. این کاربران باید از قفل پایگاه‌داده اشیاء و نحوه رفتار دستورات همزمان git maintenance run آگاه باشند. علاوه بر این، دستور git gc نباید با دستورات git maintenance run ترکیب شود. دستور git gc پایگاه‌داده اشیاء را تغییر می‌دهد اما قفل را به همان روشی که git maintenance run انجام می‌دهد اعمال نمی‌کند. در صورت امکان، از git maintenance run --task=gc به‌جای git gc استفاده کنید.

بخش‌های زیر سازوکارهای تعبیه‌شده برای اجرای نگهداری پس‌زمینه توسط git maintenance start و نحوه سفارشی‌سازی آن‌ها را شرح می‌دهند.

سازوکار استاندارد برای زمان‌بندی وظایف پس‌زمینه در سیستم‌های POSIX ابزار cron(8) است. این ابزار دستورات را بر اساس یک زمان‌بندی مشخص اجرا می‌کند. فهرست جاری وظایف زمان‌بندی‌شده توسط کاربر را می‌توان با اجرای crontab -l پیدا کرد. زمان‌بندی نوشته‌شده توسط git maintenance start شبیه به این است:

# BEGIN GIT MAINTENANCE SCHEDULE
# The following schedule was created by Git
# Any edits made in this region might be
# replaced in the future by a Git command.
0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly
0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily
0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly
# END GIT MAINTENANCE SCHEDULE

کامنت‌ها به عنوان ناحیه‌ای برای نشانه‌گذاری زمان‌بندی نوشته‌شده توسط گیت استفاده می‌شوند. هرگونه تغییر در این ناحیه با git maintenance stop کاملاً حذف شده یا با git maintenance start بازنویسی می‌شود.

ورودی crontab مسیر کامل فایل اجرایی git را مشخص می‌کند تا اطمینان حاصل شود که دستور git اجراشده همان دستوری است که git maintenance start با آن صادر شده است، مستقل از متغیر PATH. اگر همان کاربر git maintenance start را با چندین فایل اجرایی Git اجرا کند، فقط آخرین فایل اجرایی استفاده می‌شود.

این دستورات از git for-each-repo --config=maintenance.repo برای اجرای git maintenance run --schedule=<frequency> روی هر مخزن فهرست‌شده در گزینه پیکربندی چندمقداری maintenance.repo استفاده می‌کنند. این مقادیر معمولاً از پیکربندی سراسری ویژه کاربر بارگیری می‌شوند. سپس فرآیند git maintenance با استفاده از گزینه‌های پیکربندی maintenance.<task>.schedule تعیین می‌کند که کدام وظایف نگهداری برای اجرا در هر مخزن با هر <frequency> پیکربندی شده‌اند. این مقادیر از مقادیر پیکربندی سراسری یا مخزن بارگیری می‌شوند.

اگر مقادیر پیکربندی برای دستیابی به برنامه نگهداری پس‌زمینه مورد نظر شما کافی نیست، می‌توانید برنامه زمان‌بندی خود را ایجاد کنید. اگر crontab -e را اجرا کنید، یک ویرایشگر با زمان‌بندی cron ویژه کاربر شما بارگیری می‌شود. در آن ویرایشگر، می‌توانید خطوط زمان‌بندی خود را اضافه کنید. می‌توانید با اقتباس از زمان‌بندی پیش‌فرض فهرست‌شده در بالا شروع کنید، یا می‌توانید مستندات crontab(5) را برای تکنیک‌های پیشرفته زمان‌بندی مطالعه کنید. لطفاً از تکنیک‌های مسیر کامل و --exec-path از زمان‌بندی پیش‌فرض استفاده کنید تا مطمئن شوید که باینری‌های صحیح را در زمان‌بندی خود اجرا می‌کنید.

در حالی که لینوکس از cron پشتیبانی می‌کند، بسته به توزیع، ممکن است cron یک بسته اختیاری باشد و لزوماً نصب نشده باشد. در توزیع‌های مدرن لینوکس، تایمرهای systemd در حال جایگزینی آن هستند.

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

در این حالت، git maintenance start واحدهای تایمر کاربری systemd را ایجاد کرده و تایمرها را شروع می‌کند. فهرست جاری وظایف زمان‌بندی‌شده کاربر را می‌توان با اجرای systemctl --user list-timers پیدا کرد. تایمرهای نوشته‌شده توسط git maintenance start مشابه این هستند:

$ systemctl --user list-timers
NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
Thu 2021-04-29 19:00:00 CEST 42min left    Thu 2021-04-29 18:00:11 CEST 17min ago  git-maintenance@hourly.timer git-maintenance@hourly.service
Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago    git-maintenance@daily.timer  git-maintenance@daily.service
Mon 2021-05-03 00:00:00 CEST 3 days left   Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service

برای هر گزینه --schedule=<frequency> یک تایمر ثبت می‌شود.

تعریف واحدهای systemd را می‌توان در فایل‌های زیر بررسی کرد:

~/.config/systemd/user/git-maintenance@.timer
~/.config/systemd/user/git-maintenance@.service
~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer
~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer

دستور git maintenance start این فایل‌ها را بازنویسی کرده و تایمر را مجدداً با systemctl --user راه‌اندازی می‌کند، بنابراین هرگونه سفارشی‌سازی باید با ایجاد یک فایل drop-in انجام شود، یعنی یک فایل با پسوند .conf در دایرکتوری ~/.config/systemd/user/git-maintenance@.service.d.

دستور git maintenance stop تایمرهای کاربری systemd را متوقف کرده و فایل‌های ذکرشده در بالا را حذف می‌کند.

برای جزئیات بیشتر به systemd.timer(5) مراجعه کنید.

در حالی که macOS از نظر فنی از cron پشتیبانی می‌کند، استفاده از crontab -e نیاز به دسترسی‌های بالاتر دارد و فرآیند اجراشده زمینه کاربری کامل ندارد. بدون یک زمینه کاربری کامل، Git و دستیارهای اعتبارنامه‌ای آن نمی‌توانند به اطلاعات هویتی ذخیره‌شده دسترسی پیدا کنند، بنابراین برخی از وظایف نگهداری کار نخواهند کرد.

در عوض، git maintenance start با ابزار launchctl تعامل برقرار می‌کند، که روش پیشنهادی برای زمان‌بندی کارهای زمان‌دار در macOS است. زمان‌بندی نگهداری از طریق git maintenance (start|stop) به برخی از قابلیت‌های launchctl نیاز دارد که فقط در macOS 10.11 یا بالاتر در دسترس هستند.

وظایف زمان‌بندی‌شده ویژه کاربر شما به صورت فایل‌های .plist با فرمت XML در ~/Library/LaunchAgents/ ذخیره می‌شوند. با استفاده از دستور زیر می‌توانید وظایفی را که در حال حاضر ثبت شده‌اند مشاهده کنید:

$ ls ~/Library/LaunchAgents/org.git-scm.git*
org.git-scm.git.daily.plist
org.git-scm.git.hourly.plist
org.git-scm.git.weekly.plist

برای هر گزینه --schedule=<frequency> یک وظیفه ثبت می‌شود. برای بررسی نحوه توصیف هر زمان‌بندی توسط قالب XML، یکی از این فایل‌های .plist را در یک ویرایشگر باز کنید و عنصر <array> را پس از عنصر <key>StartCalendarInterval</key> بررسی نمایید.

دستور git maintenance start این فایل‌ها را بازنویسی کرده و وظایف را مجدداً در launchctl ثبت می‌کند، بنابراین هرگونه سفارشی‌سازی باید با ایجاد فایل‌های .plist خودتان با نام‌های مجزا انجام شود. به طور مشابه، دستور git maintenance stop وظایف را از launchctl لغو ثبت کرده و فایل‌های .plist را حذف می‌کند.

برای ایجاد سفارشی‌سازی‌های پیشرفته‌تر در وظایف پس‌زمینه خود، جهت کسب اطلاعات بیشتر به launchctl.plist(5) مراجعه کنید.

ویندوز از cron پشتیبانی نمی‌کند و در عوض سیستم اختصاصی خود را برای زمان‌بندی وظایف پس‌زمینه دارد. دستور git maintenance start از دستور schtasks برای ارسال وظایف به این سیستم استفاده می‌کند. می‌توانید با استفاده از برنامه زمان‌بند وظایف (Task Scheduler) همه وظایف پس‌زمینه را بررسی کنید. وظایف اضافه‌شده توسط Git دارای نام‌هایی به فرم Git Maintenance (<frequency>) هستند. رابط گرافیکی Task Scheduler راه‌هایی برای بازرسی این وظایف دارد، اما می‌توانید وظایف را در فایل‌های XML خروجی بگیرید و جزئیات را در آنجا مشاهده کنید.

توجه داشته باشید که از آنجا که Git یک برنامه کنسولی است، این وظایف پس‌زمینه یک پنجره کنسول قابل مشاهده برای کاربر جاری ایجاد می‌کنند. این مورد را می‌توان به صورت دستی با انتخاب گزینه "Run whether user is logged in or not" در Task Scheduler تغییر داد. این تغییر نیاز به وارد کردن رمز عبور دارد، به همین دلیل است که git maintenance start آن را به صورت پیش‌فرض انتخاب نمی‌کند.

اگر می‌خواهید وظایف پس‌زمینه را سفارشی‌سازی کنید، لطفاً نام وظایف را تغییر دهید تا فراخوانی‌های بعدی git maintenance (start|stop) وظایف سفارشی شما را بازنویسی نکنند.

تمام موارد زیر این خط در این بخش به طور گزینشی از مستندات git-config(1) گنجانده شده است. محتوای آن همان چیزی است که در آنجا یافت می‌شود:

maintenance.auto

این گزینه پیکربندی بولی کنترل می‌کند که آیا برخی از دستورات پس از انجام کارهای عادی خود دستور git maintenance run --auto را اجرا کنند یا خیر. مقدار پیش‌فرض true است.

maintenance.autoDetach

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

در صورت عدم تنظیم، مقدار gc.autoDetach به عنوان جایگزین استفاده می‌شود. در صورتی که هر دو تنظیم نشده باشند، مقدار پیش‌فرض true است، به این معنی که فرآیند نگهداری جدا خواهد شد.

maintenance.strategy

این گزینه پیکربندی رشته‌ای راهی را برای تعیین یکی از چند راهبرد توصیه‌شده برای نگهداری مخزن فراهم می‌کند. این بر روی وظایفی که در حین اجرای git maintenance run اجرا می‌شوند، به شرطی که هیچ آرگومان --task=<task> ارائه نشده باشد، تأثیر می‌گذارد. این تنظیم بر نگهداری دستی، نگهداری خودکار و همچنین نگهداری زمان‌بندی‌شده تأثیر می‌گذارد. وظایفی که اجرا می‌شوند ممکن است بسته به نوع نگهداری متفاوت باشند.

راهبرد نگهداری را می‌توان با تنظیم maintenance.<task>.enabled و maintenance.<task>.schedule بیشتر تنظیم کرد. در صورت تنظیم، این مقادیر به‌جای مقادیر پیش‌فرض ارائه‌شده توسط maintenance.strategy استفاده می‌شوند.

راهبردهای ممکن عبارتند از:

•none: این راهبرد دلالت بر این دارد که هیچ وظیفه‌ای اصلاً اجرا نمی‌شود. این راهبرد پیش‌فرض برای نگهداری زمان‌بندی‌شده است.
•gc: این راهبرد وظیفه gc را اجرا می‌کند.
•geometric: این راهبرد بسته‌بندی مجدد هندسی فایل‌های پک را انجام می‌دهد و ساختارهای داده کمکی را به‌روز نگه می‌دارد. این راهبرد داده‌ها را در reflog منقضی می‌کند و درخت‌های کاری را که دیگر یافت نمی‌شوند حذف می‌نماید. هنگامی که راهبرد بسته‌بندی مجدد هندسی تصمیم به بسته‌بندی همه در یکی می‌گیرد، راهبرد یک پک ضایعات (cruft pack) برای تمام اشیاء غیرقابل دسترس تولید می‌کند. اشیایی که از قبل بخشی از یک پک ضایعات هستند منقضی خواهند شد.

این راهبرد بسته‌بندی مجدد یک جایگزین کامل برای راهبرد gc است و برای مخازن بزرگ پیشنهاد می‌شود. این راهبرد پیش‌فرض برای نگهداری دستی است.

•incremental: این تنظیم برای انجام فعالیت‌های نگهداری کوچک که هیچ داده‌ای را حذف نمی‌کنند بهینه‌سازی شده است. این گزینه وظیفه gc را زمان‌بندی نمی‌کند، بلکه وظایف prefetch و commit-graph را به‌صورت ساعتی، وظایف loose-objects و incremental-repack را به‌صورت روزانه، و وظیفه pack-refs را به‌صورت هفتگی اجرا می‌کند. نگهداری دستی مخزن از وظیفه gc استفاده می‌کند.

maintenance.<task>.enabled

این گزینه پیکربندی بولی کنترل می‌کند که آیا وظیفه نگهداری با نام <task> در زمانی که هیچ گزینه --task به git maintenance run داده نشده است اجرا شود یا خیر. این مقادیر پیکربندی در صورت وجود یک گزینه --task نادیده گرفته می‌شوند. به‌طور پیش‌فرض، فقط maintenance.gc.enabled برابر با true است.

maintenance.<task>.schedule

این گزینه پیکربندی کنترل می‌کند که آیا <task> داده‌شده در طول یک دستور git maintenance run --schedule=<frequency> اجرا شود یا خیر. مقدار باید یکی از موارد "hourly" (ساعتی)، "daily" (روزانه) یا "weekly" (هفتگی) باشد.

maintenance.commit-graph.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه commit-graph چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه commit-graph با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت بیانگر این است که دستور باید زمانی اجرا شود که تعداد کامیت‌های قابل دسترس که در فایل commit-graph نیستند حداقل به اندازه مقدار maintenance.commit-graph.auto باشد. مقدار پیش‌فرض 100 است.

maintenance.loose-objects.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه loose-objects چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه loose-objects با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت بیانگر این است که دستور باید زمانی اجرا شود که تعداد اشیاء سست حداقل به اندازه مقدار maintenance.loose-objects.auto باشد. مقدار پیش‌فرض 100 است.

maintenance.loose-objects.batchSize

این گزینه پیکربندی عدد صحیح حداکثر تعداد اشیاء سست نوشته‌شده در یک فایل پک را در طول وظیفه loose-objects کنترل می‌کند. مقدار پیش‌فرض پنجاه هزار است. از مقدار 0 برای نشان دادن عدم وجود محدودیت استفاده کنید.

maintenance.incremental-repack.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه incremental-repack چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه incremental-repack با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت بیانگر این است که دستور باید زمانی اجرا شود که تعداد فایل‌های پکی که در multi-pack-index نیستند حداقل به اندازه مقدار maintenance.incremental-repack.auto باشد. مقدار پیش‌فرض 10 است.

maintenance.geometric-repack.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه geometric-repack چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه geometric-repack با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت بیانگر این است که دستور باید زمانی اجرا شود که یا فایل‌های پکی وجود دارند که برای حفظ تصاعد هندسی باید با هم ادغام شوند، یا حداقل این تعداد شیء سست وجود دارد که در یک فایل پک جدید نوشته می‌شوند. مقدار پیش‌فرض 100 است.

maintenance.geometric-repack.splitFactor

این گزینه پیکربندی عدد صحیح عاملی را که برای دنباله هندسی استفاده می‌شود کنترل می‌کند. برای جزئیات بیشتر به گزینه --geometric= در git-repack(1) مراجعه کنید. مقدار پیش‌فرض 2 است.

maintenance.reflog-expire.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه reflog-expire چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه reflog-expire با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت بیانگر این است که دستور باید زمانی اجرا شود که تعداد ورودی‌های منقضی‌شده reflog در reflog مربوط به "HEAD" حداقل به اندازه مقدار maintenance.loose-objects.auto باشد. مقدار پیش‌فرض 100 است.

maintenance.rerere-gc.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه rerere-gc چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه rerere-gc با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، هر مقدار مثبت بیانگر این است که دستور در صورتی که دایرکتوری "rr-cache" وجود داشته باشد و حداقل یک ورودی داشته باشد، صرف نظر از اینکه کهنه است یا خیر، اجرا خواهد شد. این روش ممکن است در آینده اصلاح شود. مقدار پیش‌فرض 1 است.

maintenance.worktree-prune.auto

این گزینه پیکربندی عدد صحیح کنترل می‌کند که وظیفه worktree-prune چند وقت یک‌بار باید به عنوان بخشی از git maintenance run --auto اجرا شود. اگر صفر باشد، وظیفه worktree-prune با گزینه --auto اجرا نخواهد شد. یک مقدار منفی وظیفه را مجبور می‌کند هر بار اجرا شود. در غیر این صورت، یک مقدار مثبت بیانگر این است که دستور باید زمانی اجرا شود که تعداد درخت‌های کاری قابل هرس از این مقدار فراتر رود. مقدار پیش‌فرض 1 است.

بخشی از مجموعه git(1)

2026-06-29 Git 2.55.0