Setup and Config

• git
• config
• help
• bugreport
• Credential helpers

Getting and Creating Projects

• init
• clone

Basic Snapshotting

• add
• status
• diff
• commit
• notes
• restore
• reset
• rm
• mv

Branching and Merging

• branch
• checkout
• switch
• merge
• mergetool
• log
• stash
• tag
• worktree

Sharing and Updating Projects

• fetch
• pull
• push
• remote
• submodule

Inspection and Comparison

• show
• log
• diff
• difftool
• range-diff
• shortlog
• describe

Patching

• apply
• cherry-pick
• diff
• rebase
• revert

Debugging

• bisect
• blame
• grep

Email

• am
• apply
• imap-send
• format-patch
• send-email
• request-pull

External Systems

• svn
• fast-import

Server Admin

• daemon
• update-server-info

Guides

• gitattributes
• Command-line interface conventions
• Everyday Git
• Frequently Asked Questions (FAQ)
• Glossary
• Hooks
• gitignore
• gitmodules
• Revisions
• Submodules
• Tutorial
• Workflows
• All guides...

Administration

• clean
• gc
• fsck
• reflog
• filter-branch
• instaweb
• archive
• bundle

Plumbing Commands

• cat-file
• check-ignore
• checkout-index
• commit-tree
• count-objects
• diff-index
• for-each-ref
• hash-object
• ls-files
• ls-tree
• merge-base
• read-tree
• rev-list
• rev-parse
• show-ref
• symbolic-ref
• update-index
• update-ref
• verify-pack
• write-tree

git-gc - Очистіть непотрібні файли та оптимізуйте локальний репозиторій

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]. Вміст такий самий, як і там:

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

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

1. Будь-який об’єкт з часом модифікації новішим за дату --prune зберігається разом з усім, що доступно з нього.

2. Більшість операцій, які додають об’єкт до бази даних, оновлюють час модифікації об’єкта, якщо він вже присутній, тому застосовується пункт No1.

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

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

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

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