Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.49.1 → 2.51.0 no changes
-
2.49.0
2025-03-14
- 2.47.1 → 2.48.2 no changes
-
2.47.0
2024-10-06
- 2.43.1 → 2.46.4 no changes
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 no changes
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 no changes
-
2.41.0
2023-06-01
- 2.38.1 → 2.40.4 no changes
-
2.38.0
2022-10-02
- 2.37.1 → 2.37.7 no changes
-
2.37.0
2022-06-27
- 2.31.1 → 2.36.6 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.24.1 → 2.29.3 no changes
-
2.24.0
2019-11-04
- 2.22.1 → 2.23.4 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.19.1 → 2.19.6 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.13.7 → 2.17.6 no changes
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
- 2.10.5 no changes
-
2.9.5
2017-07-30
- 2.7.6 → 2.8.6 no changes
-
2.6.7
2017-05-05
- 2.5.6 no changes
-
2.4.12
2017-05-05
- 2.1.4 → 2.3.10 no changes
-
2.0.5
2014-12-17
СИНОПСИС
git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
ОПИС
Виконує низку завдань з обслуговування в поточному репозиторії, таких як стиснення версій файлів (для зменшення місця на диску та підвищення продуктивності), видалення недоступних об’єктів, які могли бути створені в результаті попередніх викликів git add, пакування посилань, обрізання журналу посилань, видалення метаданих rerere або застарілих робочих дерев. Також може оновлювати допоміжні індекси, такі як commit-graph.
Коли запускаються звичайні операції з створення об’єктів у форматі Porcelan, вони перевіряють, чи суттєво зріс репозиторій з моменту останнього обслуговування, і якщо так, то автоматично запускають git
gc
. Дивіться gc.auto
нижче, щоб дізнатися, як вимкнути цю поведінку.
Ручний запуск git
gc
потрібен лише під час додавання об’єктів до репозиторію без регулярного запуску таких команд porcelain, для одноразової оптимізації репозиторію або, наприклад, для очищення неоптимального масового імпорту. Дивіться розділ "ОПТИМІЗАЦІЯ PACKFILE" у git-fast-import[1] для отримання додаткової інформації про випадок імпорту.
ОПЦІЇ
- --aggressive
-
Зазвичай «git gc» працює дуже швидко, забезпечуючи хороше використання дискового простору та продуктивність. Ця опція призведе до того, що «git gc» буде більш агресивно оптимізувати репозиторій, але це займе набагато більше часу. Ефекти такої оптимізації здебільшого є постійними. Дивіться розділ «АГРЕСИВНА» нижче для отримання детальної інформації.
- --auto
-
З цією опцією git gc перевіряє, чи потрібне якесь технічне обслуговування; якщо ні, то завершується без виконання жодної роботи.
Дивіться параметр
gc.auto
у розділі "КОНФІГУРАЦІЯ" нижче, щоб дізнатися, як працює ця евристика.Після того, як перевищення лімітів параметрів конфігурації, таких як
gc.auto
таgc.autoPackLimit
, запустить обробку даних, усі інші завдання обробки даних (наприклад, відновлення, робота з деревами, перефлогування…) також будуть виконані. - --[no-]detach
-
Запускати у фоновому режимі, якщо система це підтримує. Цей параметр замінює конфігурацію
gc.autoDetach
. - --[no-]cruft
-
Коли термін дії недоступних об’єктів закінчується, упакуйте їх окремо в cruft pack, а не зберігайте їх як окремі об’єкти.
--cruft
увімкнено за замовчуванням. - --max-cruft-size=<n>
-
Під час пакування недоступних об’єктів у cruft-пак обмежте розмір нових cruft-паків максимум до <n> байтів. Перевизначає будь-яке значення, вказане в конфігурації
gc.maxCruftSize
. Див. опцію--max-cruft-size
у git-repack[1] для отримання додаткової інформації. - --expire-to=<dir>
-
Під час пакування недоступних об’єктів у cruft-пак, запишіть cruft-пак, що містить обрізані об’єкти (якщо такі є), у каталог <dir>. Цей параметр має ефект лише при використанні разом з
--cruft
. Дивіться параметр--expire-to
у git-repack[1] для отримання додаткової інформації. - --prune=<date>
-
Видаляти незакріплені об’єкти, старіші за дату (за замовчуванням — 2 тижні тому, це значення можна перевизначити змінною конфігурації
gc.pruneExpire
). --prune=now видаляє незакріплені об’єкти незалежно від їхнього віку та збільшує ризик пошкодження, якщо інший процес одночасно записує дані до репозиторію; див. "ПРИМІТКИ" нижче. --prune увімкнено за замовчуванням. - --no-prune
-
Не обрізайте жодних вільних предметів.
- --quiet
-
Приховати всі звіти про хід виконання.
- --force
-
Примусово запускати
git
gc
, навіть якщо на цьому репозиторії може бути запущено інший екземплярgit
gc
. - --keep-largest-pack
-
Усі пакети, крім найбільшого (не cruft) пакету, будь-які пакети, позначені файлом
.keep
, та будь-які cruft-пакети об’єднуються в один пакет. Коли використовується ця опція,gc.bigPackThreshold
ігнорується.
АГРЕСИВНИЙ
Коли вказано опцію --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]. Вміст такий самий, як і там:
Warning
|
Missing See original version for this content. |
НОТАТКИ
«git gc» дуже старається не видаляти об’єкти, на які посилаються будь-де у вашому репозиторії. Зокрема, він зберігатиме не лише об’єкти, на які посилається ваш поточний набір гілок та тегів, але й об’єкти, на які посилається індекс, гілки віддаленого відстеження, журнали посилань (які можуть посилатися на коміти у гілках, які пізніше були змінені або перемотані) та все інше в просторі імен refs/*. Зверніть увагу, що примітка (подібна до тієї, що створена «git notes»), додана до об’єкта, не сприяє збереженню його активності. Якщо ви очікуєте, що деякі об’єкти будуть видалені, а вони не будуть видалені, перевірте всі ці місця та вирішіть, чи має сенс у вашому випадку видаляти ці посилання.
З іншого боку, коли «git gc» виконується одночасно з іншим процесом, існує ризик видалення об’єкта, який інший процес використовує, але не створив посилання на нього. Це може призвести до збою іншого процесу або пошкодження репозиторію, якщо інший процес пізніше додасть посилання на видалений об’єкт. Git має дві функції, які значно пом’якшують цю проблему:
-
Будь-який об’єкт з часом модифікації новішим за дату
--prune
зберігається разом з усім, що доступно з нього. -
Більшість операцій, які додають об’єкт до бази даних, оновлюють час модифікації об’єкта, якщо він вже присутній, тому застосовується пункт №1.
Однак ці функції не є повноцінним рішенням, тому користувачі, які одночасно виконують команди, повинні жити з певним ризиком пошкодження (який на практиці здається низьким).
ГАЧКИ
Команда git gc --auto запустить хук pre-auto-gc. Див. githooks[5] для отримання додаткової інформації.
GIT
Частина набору git[1]