Большой Git-репозиторий на ноутбуке: почему тормозит и как ускорить статус, checkout и clone

Прямой ответ

Если git status на вашем репозитории занимает секунды, а clone — десятки минут, почти всегда помогает комбинация из четырёх официальных механизмов: fsmonitor (демон слежения за файлами вместо полного сканирования), sparse-checkout (материализация только нужных каталогов), partial clone (--filter=blob:none — скачивание содержимого файлов по запросу) и commit-graph (ускорение истории). На репозиториях в сотни тысяч файлов это превращает 10–30 секунд ожидания в 1–2 секунды. Второй по значимости фактор — накопитель и антивирус: Git упирается в тысячи мелких файловых операций.

Диагностика: что именно тормозит

GIT_TRACE2_PERF=1 git status   # тайминги по этапам
git count-objects -vH          # размер объектной базы
git ls-files | wc -l           # число отслеживаемых файлов

Ориентиры: до ~50 тыс. файлов Git шустр «из коробки»; 100–500 тыс. файлов — включайте fsmonitor и commit-graph; от 500 тыс. или истории в десятки ГБ — добавляйте sparse-checkout/partial clone. Отдельно проверьте, не лежит ли репозиторий в синхронизируемой папке (OneDrive/Dropbox) — это убивает производительность гарантированно; перенесите в обычную папку.

Шаг 1. Быстрые победы для любого репозитория

git config core.fsmonitor true        # демон слежения (Git 2.37+)
git config core.untrackedcache true   # кэш untracked-файлов
git commit-graph write --reachable    # ускорение log/merge-base
git config gc.auto 1                  # регулярная сборка объектов
git maintenance start                 # фоновое обслуживание

git maintenance start регистрирует периодические задачи (commit-graph, gc, prefetch) — это официальная замена ручным ритуалам. На Windows убедитесь, что Git для Windows обновлён: fsmonitor-демон исторически появился там позже и работает стабильно в актуальных версиях.

Шаг 2. Sparse-checkout: видеть только своё

В монорепозитории вам нужны 2–3 сервиса из 80 каталогов:

git sparse-checkout init --cone
git sparse-checkout set services/billing libs/common

В cone-режиме Git материализует только перечисленные каталоги: checkout, status и diff работают с тысячами файлов вместо сотен тысяч. Переключение между задачами — git sparse-checkout set ... заново; полный список команд — git sparse-checkout list. Ограничение честно: инструменты, сканирующие «весь репозиторий» (некоторые IDE-плагины, grep по дереву), увидят только материализованную часть.

Шаг 3. Partial clone: история без гигабайтов

git clone --filter=blob:none <url>    # коммиты и деревья сразу, blobs — по запросу

Клонирование большого репозитория с историей бинарных ассетов сокращается в разы: содержимое старых файлов подкачивается лениво при checkout/diff. Цена — сеть нужна при первом обращении к старым blob'ам; для офлайн-работы комбинируйте с --filter=blob:limit=1m (не скачивать крупные файлы) разумнее полного отказа от blobs. Partial clone поддерживается GitHub/GitLab — это штатная, а не экспериментальная функция.

Диск и антивирус: недооценённые факторы

Git-репозиторий — это тысячи мелких файлов (.git/objects, рабочая копия, node_modules рядом). Практика:

1. Только SSD: на HDD git status монорепо может занимать минуту против секунды на NVMe.
2. Windows Defender: добавьте папку репозитория в исключения сканирования в реальном времени — официально рекомендуемая Microsoft настройка для dev-папок; эффект — до 2× на checkout.
3. Свободное место ≥15–20%: сборка мусора (git gc) создаёт временные pack-файлы вдвое больше объектной базы.
4. Индексация ОС: исключите рабочую папку из Windows Search Spotlight-индексации — ещё один фоновый читатель тысяч файлов.

Если после всех настроек IDE всё равно «думает» при открытии проекта — проблема уже в индексации редактора, а не в Git; как её обуздать, разобрано в статье про IDE и оперативную память.

Когда Git-подход пора менять

Симптомы «вы уперлись в масштаб»: clone даже с фильтрами занимает >15 минут; pack-файл больше 20 ГБ; merge конфликтует на lock-файлах ежедневно. Решения уровня архитектуры: разделение репозитория по сервисам + пакетный менеджер, Git LFS для бинарников (но не для кода), или специализированные системы (Microsoft/GitHub масштабируют Git серверно — VFS for Git/Scalar). Для командного проекта это решение техлида; ваша локальная часть — настройки выше.

Порядок действий: чек-лист ускорения за 10 минут

Пройдите шаги по порядку и замеряйте git status до и после каждого — так вы увидите вклад каждой настройки:

1. Обновите Git (git --version; на Windows — Git for Windows последней версии): fsmonitor и maintenance развиваются от релиза к релизу.
2. Включите быстрые победы: git config core.fsmonitor true && git config core.untrackedcache true && git maintenance start.
3. Перенесите репозиторий из синхронизируемых папок (OneDrive/Dropbox/iCloud) в обычную директорию — если он там лежал, это уже решение половины проблемы.
4. Добавьте папку проектов в исключения Windows Defender / корпоративного антивируса (на macOS аналог — исключения Spotlight для dev-каталогов).
5. Для монорепо включите cone sparse-checkout со своими каталогами; для тяжёлой истории — переклонируйте с --filter=blob:none.
6. Запишите результат: на типовом монорепо 200–400 тыс. файлов связка fsmonitor+sparse даёт ускорение git status с 8–20 с до 1–2 с — проверено на практике командами, описывающими эти механизмы в документации Git.

Отдельно про IDE: после включения sparse-checkout переиндексируйте проект (IDE должна увидеть уменьшенное дерево), иначе фоновый сканер продолжит обходить несуществующие каталоги и эффект будет смазан.

FAQ

Безопасно ли удалять .git-кэш и переклонировать репозиторий? Да, если все ваши ветки запушены. Переклонирование с --filter=blob:none — самый простой способ «починить» раздувшуюся локальную копию.

Что даёт Git LFS и не сломает ли он работу? LFS хранит большие бинарники вне истории Git. Включать имеет смысл для ассетов (модели, видео, датасеты); для кода LFS не применяется. Команда должна договориться о его использовании централизованно.

Почему после sparse-checkout CI падает? CI обычно клонирует репозиторий целиком и не наследует ваши локальные настройки — конфликта нет. Падает локальный прогон, рассчитывающий на соседние каталоги: добавьте их в sparse-набор.

Помогает ли SSD-апгрейд против медленного git? Да, если сейчас HDD или почти заполненный SSD: Git — чемпион по мелким файловым операциям. Порядок апгрейда описан в материале про апгрейд ОЗУ и SSD.

Влияет ли размер RAM на скорость Git? Почти нет: Git не держит репозиторий в памяти, он упирается в дисковые операции и CPU (сжатие объектов). Апгрейд ОЗУ ускорит IDE и сборку, но не git status; для Git важнее NVMe-диск и отключённый антивирусный сканер в папке проекта.

Источники: официальная документация Git (sparse-checkout, fsmonitor, clone-фильтры), блог GitHub о Git 2.37 (ссылки в шапке).