git fetch --write-commit-graph: когда нужен

Что даёт commit-graph после fetch

Git хранит ускоряющую структуру с данными о commits и их связях. Когда после fetch появились новые pack-файлы, старый commit-graph может не включать свежую историю. `--write-commit-graph` просит обновить структуру сразу после получения данных; настройка `fetch.writeCommitGraph=true` делает это автоматически при fetch, который скачал pack. Документация отмечает пользу для `merge-base`, `push -f` и `log --graph` среди других команд, особенно в больших историях.

Совет: Сначала измерьте, а затем включайте оптимизацию глобально.

Как попробовать без постоянной настройки

1. Измерьте типичный `git fetch` и одну медленную команду истории на крупном репозитории, чтобы был базовый ориентир.
2. Один раз выполните `git fetch --write-commit-graph` и дождитесь завершения дополнительной записи графа.
3. Повторите ту же команду истории на сопоставимом состоянии репозитория и оцените реальную разницу.
4. Если выигрыш стабилен, задайте `git config fetch.writeCommitGraph true` на нужном уровне.
5. Если дополнительная запись мешает узкому CI-job, используйте `--no-write-commit-graph` для конкретного запуска.

Почему это не всегда нужно включать везде

На маленькой истории сама запись commit-graph может стоить больше времени, чем экономит в последующих командах. В ephemeral CI-контейнере, который делает один fetch и сразу удаляется, выгода также ограничена. Кроме того, Git уже запускает auto-maintenance по своей логике, поэтому сначала измеряйте реальный bottleneck. Эта опция полезна там, где один рабочий clone живёт долго и регулярно получает большие порции новой истории.

Предупреждение: Не ожидайте уменьшения сетевого трафика: commit-graph ускоряет работу с историей после загрузки.

Хороший кандидат для включения

• монорепозиторий с длинной историей;
• частые fetch в одном постоянном clone;
• заметно медленные обходы commit ancestry;
• есть возможность измерить эффект до и после.

Как проверить, что commit-graph действительно обновился

После fetch можно использовать служебные команды Git для проверки commit-graph либо сравнить время повторяемых операций истории до и после. Главное — не судить по одному случайному запуску: файловый кэш ОС тоже влияет на скорость, поэтому полезнее несколько одинаковых измерений на одном clone.

Когда ускорение будет заметно

Commit-graph особенно полезен в больших репозиториях с глубокой историей, где часто выполняются операции поиска merge-base, построения графа или проверки достижимости коммитов. В маленьком проекте разница может быть незаметна. Поэтому включать запись графа имеет смысл после измерения реальной задержки, а не как обязательный флаг каждого `fetch`; дополнительный файл тоже нужно поддерживать актуальным.

Пример для большого монорепозитория

Разработчики ежедневно делают fetch сотен новых commits, а затем часто запускают `git log --graph` и инструменты, использующие merge-base. Один дополнительный шаг записи графа после fetch может окупиться множеством последующих операций. В коротком CI-job, который выполняет только checkout и build, тот же шаг может не дать заметной пользы.

Важно: В одноразовых CI-clone дополнительная запись может быть лишней.

Что учитывать

На маленькой истории сама запись commit-graph может стоить больше времени, чем экономит в последующих командах. В ephemeral CI-контейнере, который делает один fetch и сразу удаляется, выгода также ограничена. Кроме того, Git уже запускает auto-maintenance по своей логике, поэтому сначала измеряйте реальный bottleneck. Эта опция полезна там, где один рабочий clone живёт долго и регулярно получает большие порции новой истории.

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-23. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• git-fetch Documentation