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

Git ніколи не каже вам, у скільки обходиться репозиторій. Він продовжує працювати за будь-якого стану своєї бази об’єктів, тому першою ознакою біди зазвичай стає клон, що ледь повзе, або ноутбук без вільного місця — задовго після моменту, коли все виправила б одна команда.

Ця панель — той самий відсутній індикатор: куди поділося місце, скільки з нього можна повернути і що робить кожне завдання ще до того, як ви його запустите.

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

Використання диска, поділене на packed, loose та недосяжні об’єкти, із завданнями обслуговування знизу

Як читати числа

Усе береться з git count-objects -v і справжнього обходу досяжності — нічого не оцінюється приблизно.

Рядок	Що це таке	Чому росте
Packed	Об’єкти всередині packfile, стиснуті та дельтифіковані	Це здоровий стан
Loose	По одному файлу на об’єкт, майже без стиснення	Кожен коміт, кожен фетч пише саме такі
Недосяжні	Об’єкти, на які вже ніщо не вказує	Відкинуті коміти, виправлені повідомлення, покинуті ребейзи

Число поруч із Loose — «n об’єктів, m уже запаковані» — те, за яким варто стежити. Ці m зберігаються двічі: один раз як loose, один раз усередині пака. Це чисте дублювання, і git gc — саме те, що його схлопує.

Недосяжні — це ще не сміття. Саме завдяки цим об’єктам git reflog повертає коміт, який ви скинули. Git тримає їх два тижні цілком свідомо.

Завдання

Кнопка	Що виконує	Ціна
Оптимізувати	`git gc`	Від секунд до хвилини. Майже завжди правильна відповідь
Перепакувати з нуля	`git gc --aggressive`	Хвилини на великому репозиторії. Перераховує кожну дельту
Перебудувати граф комітів	`git commit-graph write --reachable`	Швидко. Помітно пришвидшує обходи логу та графа
Перевірити цілісність	`git fsck --dangling`	Повільно на великому репозиторії, нічого не змінює
Прибрати недосяжні зараз	`git gc --prune=now`	Нищить страхувальну сітку рефлогу

Оптимізувати — те, по що варто тягнутися. Воно пакує loose-об’єкти, прибирає те, що недосяжне понад два тижні, і лишає нещодавню історію відновлюваною.

Перепакувати з нуля перехвалене. Воно викидає кожну наявну дельту й рахує з нуля, що займає хвилини й зазвичай економить кілька відсотків проти звичайного gc. Варте одного запуску після імпорту величезної історії; не варте регулярного повторення.

Прибрати недосяжні зараз спершу перепитує, і в підтвердженні сказано, скільки об’єктів і скільки місця. Після нього коміт, який ви скинули годину тому, вже не відновити — запис у рефлозі може ще бути в списку, але об’єкта за ним уже немає.

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

git fsck перевіряє, що кожен об’єкт, на який посилається інший об’єкт, справді присутній і внутрішньо узгоджений.

Dangling-об’єкти — це нормально. Це ті самі недосяжні, перелічені поіменно. Репозиторій із сотнями таких після ребейзу здоровий.
Відсутні об’єкти — це пошкодження: обірваний запис, поганий диск, перервана передача. Якщо такі з’являються, не перепаковуйте: перепакування пошкодженої бази здатне перетворити відновлювану проблему на остаточну. Клонуйте справну копію з віддаленого репозиторію й перенесіть свої незапушені гілки бандлом.

Фонове обслуговування

Прапорець реєструє репозиторій у git maintenance, яке пакує й передвантажує за розкладом, що його запускає ваша операційна система (launchd, systemd або Task Scheduler).

Тут немає нічого специфічного для Gitcito: той самий розклад обслуговує і ваш термінал, а git maintenance unregister скасовує його звідки завгодно. Знявши прапорець, ви робите рівно це — і лишаєте розклад на місці для решти зареєстрованих репозиторіїв.

Обмеження, про які варто знати

Кількість недосяжних потребує повного обходу досяжності, тож відкриття панелі на дуже великому репозиторії займає мить. Це чесне число, а не оцінка.
Розміри — це те, що віддає диск, а не довжина вмісту. Loose-об’єкт на 400 байтів однаково займає блок у 4 КБ — саме тому тисяча таких коштує мегабайти, і саме тому їх варто пакувати.
Робоче дерево або сабмодуль має власний .git, тож показаний розмір стосується лише цього репозиторію.
Обслуговування не вміє зменшувати історію. Якщо блоб на 400 МБ лежить у коміті, він досяжний, і gc триматиме його вічно — це вже видалення файлу з історії, інша й значно руйнівніша операція.
Gitcito ніколи не запускає gc у вас за спиною. Власний gc --auto git усе ще може це робити, як робив завжди; якщо він падає, то лишає нотатку в .git/gc.log, і ця панель її показує.

Дивіться також: Видалення файлу з історії · Бандли та архіви · Відновлення