Git WindowsLinuxmacOS

Git: файл удалён из истории, но репозиторий не уменьшился

  • Обновлено
  • Чтение ≈ 5 минут

Краткий ответ

После переписывания истории (например, с помощью git-filter-repo) ветки могут больше не ссылаться на удалённый большой файл, но папка .git остаётся большой: старые объекты ещё удерживаются локальными журналами, дополнительными ссылками либо включены в pack-файлы до обслуживания. Это не означает, что нужно сразу принудительно удалять объекты.

В этой статье
  1. Что означает проблема
  2. Как отличить причины
  3. Пошаговая диагностика и решение
  4. Команды для проверки и исправления
  5. Как проверить результат и что делать, если не помогло

#Что означает проблема

После переписывания истории Git старые объекты не обязательно исчезают физически сразу: их могут удерживать ссылки, журналы reflog, резервные или скрытые ветки и pack-файлы до обслуживания. Размер локальной папки .git и размер репозитория на сервере меняются независимо. В статье предполагается, что история уже очищена по отдельному согласованному плану; если файл удалён только обычным коммитом, он всё ещё есть в старой истории и этот случай следует сначала отличить.

#Как отличить причины

Возможная причинаКак узнатьЧто делать
Файл всё ещё есть в достижимой историиПереписаны не все ветки или метки, либо файл удалён только из последнего состояния.Поиск по всем ссылкам git log --all -- путь по-прежнему находит старый коммит.Уточнить, какие ссылки удерживают старую историю; повторная миграция только с участниками проекта.
Историю уже переписали, но остались старые объектыЗаписи reflog или упакованные пока недостижимые объекты ещё могут занимать место.Поиск файла в обычной истории пуст, но git count-objects -vH показывает существенный объём size-pack.Разобрать локальные журналы и срок хранения; без спешки дождаться согласованного обслуживания.
Размер сравнивают в разных местахНовая история в одной копии не приводит к автоматическому уменьшению старого клона или сервера.Свежий независимый клон заметно меньше локальной рабочей папки либо сервер продолжает хранить старые ссылки.Снять отдельно размеры каждой копии и проверить политику хостинга.
Большое место занимают не объекты историиВнутри рабочей папки сохранились бинарные сборки, кэш или неотслеживаемые файлы.Размер .git меньше ожидаемого, но весь каталог проекта остаётся большим.Проверить объём .git отдельно от рабочей папки, не удаляя файлы.

#Пошаговая диагностика и решение

  1. Проверьте, какой репозиторий и какой размер вы сравниваетеОткройте проект в VS Code («Файл» → «Открыть папку»), затем «Терминал» → «Создать терминал». Выполните git --version, git rev-parse --show-toplevel и git status -sb. Запишите путь и версию. В файловом менеджере посмотрите размер скрытого каталога .git отдельно от всего проекта. Для bare-репозитория на сервере каталога рабочего дерева может не быть; не путайте его с локальным клоном.
  2. Убедитесь, что история действительно очищенаВ терминале выполните git log --all --oneline -- путь/к/удалённому/файлу, подставив известный прежний путь. Если выводит коммиты, файл всё ещё находится в истории одной из известных веток или меток: сначала выясните какую ссылку забыли при миграции. Если вывода нет, не считайте вопрос окончательно решённым: файл мог иметь другое имя. При обнаружении секретов немедленно отзовите ключи/пароли, не надеясь на очистку истории.
  3. Снимите показатели хранилища Git без очисткиВыполните git count-objects -vH. В строке size-pack указан суммарный размер упакованных объектов в единицах для чтения, а size относится к свободным объектам. Сохраните этот результат до дальнейшей диагностики и не используйте git gc --prune=now: он может преждевременно удалить коммиты, которые ещё требуются для восстановления.
  4. Проверьте оставшиеся ссылки и журналыКоманды git for-each-ref --format="%(refname)" и git reflog --all --date=iso только показывают локальные ссылки и журнал их перемещений. Обратите внимание на резервные ссылки, старые ветки, временные refs и записи до операции переписывания. Не удаляйте их по названию: часть могла быть создана программой или политикой резервирования.
  5. Проверьте недостижимые объекты только при достаточных ресурсахЕсли репозиторий очень большой, согласуйте длительную проверку с администратором. Затем на копии или в подходящее окно обслуживания используйте git fsck --full --no-reflogs --unreachable: это диагностический просмотр объектов, на которые не ссылаются обычные ссылки при игнорировании журналов reflog. Наличие строк unreachable blob или unreachable commit не означает, что их можно безопасно удалить: среди них могут быть единственные копии работы.
  6. Сравните со свежим клоном и удалённым серверомЕсли есть доступ и достаточно свободного места, создайте новый независимый клон в другой папке штатной кнопкой «Клонировать репозиторий» в VS Code либо обычной командой git clone по проверенному адресу. Не заменяйте исходный клон. Если новый клон мал, а прежний велик, проблема, вероятно, в оставшихся локальных объектах. Если оба велики, проверьте серверные ветки/метки и политики хранения с администратором.
  7. Обсудите обслуживание с владельцами до удаления объектовПеред любыми операциями по освобождению места убедитесь, что резервная копия .git создана и действительно содержит нужные прежние коммиты, а у участников нет незавершённой работы с этими ссылками. На серверных платформах очистка старых объектов может выполняться собственными средствами и по расписанию. Запросите процедуру у администратора; в этой инструкции нет команд ускоренного удаления reflog или немедленного удаления недостижимых объектов.
  8. После согласованного обслуживания сравните цифры повторноПовторно выполните git count-objects -vH и измерьте размер .git, а затем отдельно проверьте размер на сервере и нового клона. Если новая история не содержит файл и размеры снизились там, где ожидалось, задача выполнена. Если локальное место не освободилось, сохраните показатели до/после и выведите список refs для специалиста, не выполняя повторную очистку вслепую.

#Команды для проверки и исправления

Linux · Терминал (Bash)Команда
Запускать из терминала корня проекта обычным пользователем. -vH показывает статистику объектов в удобных единицах, команды ничего не удаляют.
git --version
git rev-parse --show-toplevel
git status -sb
git count-objects -vH
Linux · Терминал (Bash)Команда
Замените путь на тот, который файл имел до удаления. --all просматривает известные ветки и метки, -- отделяет путь.
git log --all --oneline -- путь/к/удалённому/файлу
Linux · Терминал (Bash)Команда
Команды только показывают имена ссылок и локальный журнал изменений; могут выводить имена внутренних веток. Не публикуйте служебные данные без согласования.
git for-each-ref --format="%(refname)"
git reflog --all --date=iso
Linux · Терминал (Bash)Команда
Диагностическая, но потенциально ресурсоёмкая проверка; запускайте в копии или после согласования окна работ. --no-reflogs игнорирует reflog при определении достижимости. Результат не является разрешением на удаление объектов.
git fsck --full --no-reflogs --unreachable

#Как проверить результат и что делать, если не помогло

Проверка проводится по трём независимым признакам: старый файл не виден в необходимой истории, новая копия имеет ожидаемый размер, а размер локального или серверного хранилища после согласованного обслуживания уменьшился. Если эти результаты расходятся, сохраните git count-objects -vH, имена оставшихся ссылок и сведения о месте измерения, затем передайте их администратору. Не пытайтесь сократить папку .git ручным удалением pack-файлов.

non-fast-forward Git: «rejected — non-fast-forward» / «failed to push some refs» — решение Git не даёт отправить изменения, если удалённая ветка ушла вперёд. Сначала нужно получить чужие коммиты: `git pull --rebase` (или `git pull`) и разрешить конфликты, зате… Программирование и базы данных Git Git Git: Automatic merge failed — конфликт слияния — причины и решение Откройте файлы с маркерами конфликта, выберите нужный код и выполните commit. Программирование и базы данных Git Linux Git: fatal: not a git repository — причины и решение Перейдите в каталог репозитория или выполните git init. Программирование и базы данных Git Linux Git: Permission denied (publickey) при работе с GitHub по SSH — причины и решение «Permission denied (publickey)» при работе с GitHub по SSH значит, что у GitHub нет вашего публичного ключа или ssh не использует нужный закрытый. Сгенерируйте ключ, доб… Программирование и базы данных Git LinuxWindowsmacOS Git: failed to push some refs — remote rejected — причины и решение «failed to push some refs … remote rejected» значит, что сервер отклонил push: защищённая ветка, нет прав, файл слишком большой или сработал хук. Прочитайте строки remot… Программирование и базы данных Git LinuxWindowsmacOS

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.