Загальний розмір:
git count-objects -vH
count: 0
size: 0 bytes
in-pack: 48213
packs: 1
size-pack: 312.40 MiB
size-pack - скільки займають упаковані об'єкти, тобто фактичний розмір історії. count і size - ще не запаковані об'єкти; після git gc вони переходять у pack.
Що саме роздуває - найбільші об'єкти в історії:
git rev-list --objects --all \
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
| awk '$1 == "blob"' \
| sort -k3 -n -r \
| head -20
Список найбільших файлів за всю історію з їхніми шляхами - навіть тих, яких уже немає в поточному коді.
Типові знахідки:
- дамп бази (
backup.sql), закомічений «тимчасово» і потім видалений - у робочому каталозі його немає, а в історії він назавжди; vendor/чиnode_modules/, які колись потрапили в репозиторій;- зібрані фронтенд-файли (
public/build), що змінюються з кожним комітом; - медіафайли й архіви.
Зручний інструмент - git-sizer (від GitHub): аналізує репозиторій і повідомляє про проблеми - надто великі файли, дерева з тисячами файлів, надто довгі шляхи:
git-sizer --verbose
Що робити зі знайденим:
- якщо файл ще в поточному коді - видалити, додати в
.gitignore, великі ресурси перенести в LFS чи об'єктне сховище; - якщо лише в історії - розмір зменшить тільки переписування історії (
git filter-repo), з усіма наслідками для команди. Часто простіше змиритися: для розробників допомагає частковий клон; - профілактика: перевірка розміру файлів у pre-commit чи CI, правила push у GitHub, що відхиляють файли понад ліміт (GitHub і так блокує файли понад 100 МБ).