Git WindowsLinuxmacOS

Git: push отклонён сервером из-за ограничения размера одного файла

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

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

Некоторые Git-серверы (включая управляемые корпоративные GitLab и другие хранилища) ограничивают размер отдельных файлов в обычном Git. Даже когда большой файл уже удалён последним коммитом, при отправке всё равно передаются коммиты, где он существовал. Здесь разбирается отказ со стороны принимающего сервера, а не стандартная ошибка GitHub с конкретным пределом 100 МиБ.

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

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

Некоторые Git-серверы (включая управляемые корпоративные GitLab и другие хранилища) ограничивают размер отдельных файлов в обычном Git. Даже когда большой файл уже удалён последним коммитом, при отправке всё равно передаются коммиты, где он существовал. Здесь разбирается отказ со стороны принимающего сервера, а не стандартная ошибка GitHub с конкретным пределом 100 МиБ.

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

Возможная причинаКак узнатьЧто делать
Лимит установлен принимающей сторонойПредварительная серверная проверка отклоняет новый объект, превышающий корпоративный порог.В выводе push указаны pre-receive hook declined, file size limit или размер конкретного файла.Сверить лимит, имя и размер объекта с настройками сервера.
Большой файл остался в ещё не опубликованной историиФайл добавили, а потом удалили в следующем коммите: старый объект всё равно включён в диапазон отправки.git log --all -- путь показывает старое добавление; текущий git ls-files пуст.Определить, где он был впервые сохранён, и согласовать исправление локальных коммитов.
Нужен отдельный способ хранения двоичных данныхСервер разрешает Git LFS или внешнее хранилище артефактов.Типичный объект — видео, архив, резервная копия или файл весом сотни мегабайт.Согласовать LFS и правила доставки данных, а не увеличивать лимит вслепую.

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

  1. Сохраните полный текст отказа и проверьте адрес сервераОткройте проект в VS Code, выберите «Терминал» → «Создать терминал» и введите git remote -v и git status -sb. Скопируйте строки ошибки из предыдущего git push, особенно имя файла, размер, ограничение и remote rejected. Не выкладывайте в открытый доступ адреса внутренних систем или токены. Если сервер сообщает protected branch, запрет подписи или отсутствие прав, размер файла может быть ни при чём. Перед остальными командами выполните git --version: в ответ должна появиться установленная версия Git. Если терминал сообщает, что git не найден, проверьте установку Git и доступность команды в этом терминале; не продолжайте операции наугад.
  2. Сверьте правила хранилища с администраторомОткройте веб-интерфейс своего Git-сервера в браузере и страницу настроек проекта, если у вас есть доступ. Поскольку конкретные пункты интерфейса GitLab и внутренних систем различаются, запросите у администратора точный порог максимального файла и поддержку Git LFS. Не отправляйте один и тот же файл повторно и не меняйте серверные ограничения самостоятельно.
  3. Найдите файл в текущем дереве и историиВ терминале Git выполните git ls-files -- путь/к/файлу, заменив путь из ошибки. Если вывод есть, файл отслеживается сейчас; если нет, просмотрите git log --all --oneline -- путь/к/файлу. Это позволяет понять, сохранился ли объект в старом коммите. Если сервер назвал SHA объекта вместо пути, передайте его специалисту для точной идентификации.
  4. Если файл только подготовлен к коммиту, уберите его из индексаПрименяйте только когда большой файл ещё НЕ закоммичен. Проверьте git status; если файл отмечен как новый в подготовленных к коммиту, выполните git restore --staged -- путь/к/файлу. Рабочий файл останется на диске, но исчезнет из будущего коммита. Для файла, который был уже закоммичен, эта команда НЕ удалит его из истории; переходите к следующему шагу.
  5. Если файл попал только в последний локальный коммит, не опубликованный нигдеУбедитесь у коллег, что этот коммит не ушёл на другие серверы и на нём никто не основывает ветку. Сделайте отдельную резервную копию проекта, проверьте git log -1 --oneline и git show --stat HEAD. При подтверждении можно удалить путь только из индекса через git rm --cached -- путь/к/файлу, затем сделать git commit --amend --no-edit. Исходный файл останется в рабочей папке, однако SHA последнего коммита изменится. Не применяйте такой приём для merge-коммита, общей ветки или файла в более ранних коммитах.
  6. При большом файле в нескольких коммитах остановите автоматический откатЕсли удаление затрагивает более раннюю историю, не пытайтесь скрыть объект отдельным новым коммитом или запускать git reset --hard. Подготовьте перечень локальных коммитов, пути и размеры для сопровождающего репозитория. Исправление может потребовать переписать неопубликованную ветку, но это отдельная согласованная миграция с сохранением копий и проверкой всех ссылок.
  7. Выберите для больших файлов LFS или внешнее хранилищеЕсли сервер поддерживает LFS, откройте его официальную документацию и согласуйте с командой правила отслеживания нужного расширения и доступное хранилище. Важно: установка Git LFS для будущих файлов не удаляет уже созданные большие объекты из истории. Для логов, архивов сборки и резервных копий обычно безопаснее оставить их в специализированном хранилище, не в Git.
  8. Повторите отправку только после проверки диапазона коммитовУбедитесь, что целевая ветка и её адрес верны, сохраните резервную копию, затем снова выполните обычный git push без --force. Если сервер сообщает тот же объект, значит он всё ещё есть среди отправляемых коммитов; сохраните текст и обратитесь к администратору. Успех подтверждается появлением ветки и её коммитов в веб-интерфейсе.

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

Linux · Терминал (Bash)Команда
Только показывают адрес сервера, ветку и последний коммит; не нужны права администратора.
git remote -v
git status -sb
git log -1 --oneline
Linux · Терминал (Bash)Команда
Подставьте действительный путь проблемного файла в ОБОИХ местах. -- ограничивает обработку путём, --all просматривает известные ссылки.
git ls-files -- путь/к/файлу
git log --all --oneline -- путь/к/файлу
Linux · Терминал (Bash)С осторожностью
Только для файла, который ещё не вошёл ни в один коммит и сейчас добавлен в индекс. Рабочая копия файла сохраняется; замените путь.
git restore --staged -- путь/к/файлу

Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

Linux · Терминал (Bash)Риск потери данных
ТОЛЬКО если файл в последнем, ещё нигде не опубликованном обычном коммите, и после проверенной резервной копии. Первой командой убирается файл из индекса, второй меняется SHA коммита. Подставьте свой путь. Не применяйте на общей истории!
git rm --cached -- путь/к/файлу
git commit --amend --no-edit

Эта команда может привести к потере данных или существенным изменениям. Проверьте параметры, резервную копию и возможность отката.

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

После исправления обычный git push проходит без сообщения о лимите, а сервер показывает ожидаемый новый коммит. Если файл всё ещё упоминается, значит он находится в другом коммите диапазона или лимит касается других объектов. Сохраните push-вывод для сопровождающего сервера; не повышайте лимиты без расчёта места.

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

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