З часом у репозиторії накопичуються незапаковані об'єкти (кожен новий коміт створює окремі файли), недосяжні об'єкти (після rebase, reset, видалення гілок) і багато pack-файлів після кожного fetch. Це сповільнює операції й займає місце.
git gc (garbage collection):
- пакує окремі об'єкти в pack-файли з дельта-стисненням;
- видаляє недосяжні об'єкти, старші за термін (за замовчуванням 2 тижні, і лише ті, на які не посилається reflog - а reflog зберігає записи 90 днів, недосяжні - 30);
- упаковує посилання в
packed-refs, оновлює commit-graph.
git gc # звичайне прибирання
git gc --aggressive # повільне глибоке перепакування - рідко потрібне
git gc --prune=now # видалити недосяжні об'єкти негайно
git gc --auto Git запускає сам після деяких команд (commit, merge, fetch), коли незапакованих об'єктів понад 6700 чи pack-файлів понад 50. Тому вручну запускати gc зазвичай не потрібно.
Проблема автоматичного gc у великих репозиторіях: він запускається посеред роботи й може блокувати на хвилини.
git maintenance - сучасна заміна: обслуговування у фоні за розкладом:
git maintenance start
Реєструє репозиторій і задачі в системному планувальнику (launchd на macOS, systemd чи cron на Linux, Task Scheduler на Windows):
| Задача | Частота | Що робить |
|---|---|---|
prefetch |
щогодини | фоновий fetch у спеціальні ref-и - ваш git fetch потім майже миттєвий |
commit-graph |
щогодини | оновлює граф комітів для швидкого log і злиттів |
loose-objects |
щодня | пакує окремі об'єкти |
incremental-repack |
щодня | поступово об'єднує pack-файли без повного перепакування |
git maintenance run --task=gc # вручну конкретну задачу
git maintenance stop
Коли запускати вручну:
- після видалення великих файлів з історії (
git filter-repo) -git gc --prune=now, щоб звільнити місце; - після масового імпорту чи міграції репозиторію;
- для невеликого проєкту нічого робити не треба - автоматичного
gcдостатньо.
На сервері (GitHub, GitLab) обслуговування виконує хостинг.