git-gc — Очищення від непотрібних файлів та оптимізація локального репозиторію

Виконує низку завдань з обслуговування в поточному репозиторії, таких як стиснення версій файлів (для зменшення місця на диску та підвищення продуктивності), видалення недоступних обʼєктів, які могли бути створені в результаті попередніх викликів git add, пакування посилань, обрізання журналу посилань (reflog), видалення метаданих rerere або застарілих робочих дерев. Також може оновлювати допоміжні індекси, такі як commit-graph.

Під час виконання типових операцій з Porcelain, що створюють об’єкти, система перевіряє, чи значно збільшився розмір репозиторію з моменту останнього обслуговування, і, якщо так, автоматично запускає команду git gc. Щоб дізнатися, як вимкнути цю функцію, див. розділ gc.auto нижче.

Виконання команди git gc вручну може знадобитися лише у випадках, коли об’єкти додаються до репозиторію без регулярного виконання таких допоміжних команд, для одноразової оптимізації репозиторію або, наприклад, для виправлення наслідків неідеального масового імпорту. Детальнішу інформацію щодо імпорту див. у розділі «ОПТИМІЗАЦІЯ PACKFILE» на сторінці git-fast-import[1].

Коли вказано опцію --aggressive, git-repack[1] буде викликано з прапорцем -f, який, своєю чергою, передасть --no-reuse-delta до git-pack-objects[1]. Це призведе до видалення будь-яких наявних дельт та їх переобчислення, що призведе до значно більших витрат часу на перепакування.

Наслідки цього здебільшого стійкі, наприклад, коли пакунки та незакріплені обʼєкти обʼєднуються в один пакунок, наявні дельти в цьому пакунку можуть бути використані повторно, але також є різні випадки, коли ми можемо вибрати неоптимальну дельту з новішого пакунку.

Крім того, надання параметра --aggressive змінить опції --depth та --window, що передаються до git-repack[1]. Дивіться налаштування gc.aggressiveDepth та gc.aggressiveWindow нижче. Використовуючи більший розмір вікна, ми з більшою ймовірністю знайдемо оптимальніші дельти.

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

Все, що знаходиться нижче цього рядка в цьому розділі, вибірково включено з документації git-config[1]. Вміст такий самий, як і там:

Команда git gc намагається не видаляти об’єкти, на які є посилання в будь-якій частині вашого репозиторію. Зокрема, вона збереже не тільки об’єкти, на які посилаються ваші поточні гілки та теги, а й об’єкти, на які посилаються індекс, гілки віддаленого відстеження, reflogs (які можуть посилатися на коміти в гілках, що пізніше були змінені або відкочені), а також будь-що інше в просторі імен refs/* Зверніть увагу, що примітка (такого типу, що створюється командою git notes), прикріплена до обʼєкта, не сприяє збереженню обʼєкта. Якщо ви очікуєте, що деякі обʼєкти будуть видалені, а вони не видаляються, перевірте всі ці місця та вирішіть, чи є сенс у вашому випадку для видалення цих посилань.

З іншого боку, коли git gc виконується одночасно з іншим процесом, існує ризик видалення обʼєкта, який інший процес використовує, але не створив посилання на нього. Це може призвести до збою іншого процесу або пошкодження репозиторію, якщо інший процес пізніше додасть посилання на видалений обʼєкт. Git має дві функції, які значно помʼякшують цю проблему:

Однак ці функції не є повноцінним рішенням, тому користувачі, які одночасно виконують команди, повинні жити з певним ризиком пошкодження (який на практиці здається низьким).

Команда git gc --auto запустить гачок pre-auto-gc. Див. githooks[5] для отримання додаткової інформації.

git-prune[1] git-reflog[1] git-repack[1] git-rerere[1]

Частина набору git[1]