Обслуживание репозитория

Git никогда не говорит, во что обходится репозиторий. Он продолжает работать при любом состоянии своей базы объектов, поэтому первым признаком беды обычно оказывается еле ползущий клон или ноутбук, на котором кончилось место, — сильно позже того момента, когда всё чинилось одной командой.

Эта панель — недостающий индикатор: куда ушло место, сколько из него можно вернуть и что делает каждая задача, прежде чем вы её запустите.

⌘K → Обслуживание репозитория.

Использование диска, разложенное на упакованное, рыхлое и недостижимое, а под ним задачи обслуживания

Как читать цифры

Всё берётся из git count-objects -v и настоящего обхода достижимости — ничего не оценивается на глаз.

Строка	Что это	Почему растёт
Упаковано	Объекты внутри packfile, сжатые и хранящиеся дельтами	Это здоровое состояние
Рыхлые	По файлу на объект, почти без сжатия	Их пишет каждый коммит и каждый фетч
Недостижимые	Объекты, на которые уже ничто не указывает	Отброшенные коммиты, поправленные сообщения, брошенные ребейзы

Число рядом с Рыхлые — «n объектов, m уже упакованы» — то самое, за которым стоит следить. Эти m хранятся дважды: один раз рыхлыми, один раз внутри пака. Это чистое дублирование, и схлопывает его именно git gc.

Недостижимое — это ещё не мусор. Именно эти объекты позволяют git reflog вернуть коммит, который вы сбросили. Git держит их две недели намеренно.

Задачи

Кнопка	Запускает	Цена
Оптимизировать	`git gc`	От секунд до минуты. Почти всегда правильный ответ
Переупаковать с нуля	`git gc --aggressive`	Минуты на большом репозитории. Пересчитывает каждую дельту
Перестроить граф коммитов	`git commit-graph write --reachable`	Быстро. Заметно ускоряет обходы лога и графа
Проверить целостность	`git fsck --dangling`	Медленно на большом репозитории, ничего не меняет
Удалить недостижимое сейчас	`git gc --prune=now`	Уничтожает страховочную сетку reflog

Оптимизировать — то, за чем стоит тянуться. Она упаковывает рыхлые объекты, удаляет то, что недостижимо дольше двух недель, и оставляет недавнюю историю восстановимой.

Переупаковать с нуля переоценена. Она выбрасывает все существующие дельты и пересчитывает их с нуля, что занимает минуты и обычно экономит несколько процентов по сравнению с обычным gc. Стоит сделать один раз после импорта огромной истории; не стоит делать регулярно.

Удалить недостижимое сейчас сначала спрашивает, и в подтверждении сказано, сколько объектов и сколько места. После неё коммит, который вы сбросили час назад, восстановить нельзя — запись в reflog может ещё числиться, но объекта за ней уже нет.

Проверка целостности

git fsck проверяет, что каждый объект, на который ссылается другой объект, действительно на месте и внутренне непротиворечив.

Висячие объекты — это нормально. Это те самые недостижимые, перечисленные поимённо. Репозиторий с сотнями таких после ребейза здоров.
Отсутствующие объекты — это повреждение: оборванная запись, плохой диск, прерванная передача. Если такие появились, не переупаковывайте: переупаковка повреждённой базы способна превратить поправимую проблему в необратимую. Склонируйте хорошую копию с удалённого репозитория и перенесите туда свои незапушенные ветки бандлом.

Фоновое обслуживание

Флажок регистрирует репозиторий в git maintenance, который упаковывает и предзагружает по расписанию, которое исполняет ваша операционная система (launchd, systemd или Task Scheduler).

Здесь нет ничего специфичного для Gitcito: то же расписание обслуживает и ваш терминал, а git maintenance unregister отменяет его откуда угодно. Снятие флажка делает ровно это и оставляет само расписание на месте — для всех прочих зарегистрированных репозиториев.

Ограничения, о которых стоит знать

Счётчику недостижимых нужен полный обход достижимости, поэтому открытие панели на очень большом репозитории занимает мгновение. Это честное число, а не оценка.
Размеры — это то, что отдаёт диск, а не длина содержимого. Рыхлый объект на 400 байт всё равно занимает блок в 4 КБ — вот почему тысяча таких стоит мегабайты и почему их стоит упаковать.
У рабочего дерева или сабмодуля свой .git, так что показанный размер — только этого репозитория.
Обслуживание не может сжать историю. Если блоб на 400 МБ лежит в коммите, он достижим, и gc будет хранить его вечно — это уже удаление файла из истории, другая и куда более разрушительная операция.
Gitcito никогда не запускает gc у вас за спиной. Собственный gc --auto самого git по-прежнему может это делать, как делал всегда; если он падает, то оставляет запись в .git/gc.log, которую эта панель показывает.

См. также: Удаление файла из истории · Бандлы и архивы · Восстановление