#Что означает проблема
Некоторые Git-серверы (включая управляемые корпоративные GitLab и другие хранилища) ограничивают размер отдельных файлов в обычном Git. Даже когда большой файл уже удалён последним коммитом, при отправке всё равно передаются коммиты, где он существовал. Здесь разбирается отказ со стороны принимающего сервера, а не стандартная ошибка GitHub с конкретным пределом 100 МиБ.
#Как отличить причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Лимит установлен принимающей сторонойПредварительная серверная проверка отклоняет новый объект, превышающий корпоративный порог. | В выводе push указаны pre-receive hook declined, file size limit или размер конкретного файла. | Сверить лимит, имя и размер объекта с настройками сервера. |
| Большой файл остался в ещё не опубликованной историиФайл добавили, а потом удалили в следующем коммите: старый объект всё равно включён в диапазон отправки. | git log --all -- путь показывает старое добавление; текущий git ls-files пуст. | Определить, где он был впервые сохранён, и согласовать исправление локальных коммитов. |
| Нужен отдельный способ хранения двоичных данныхСервер разрешает Git LFS или внешнее хранилище артефактов. | Типичный объект — видео, архив, резервная копия или файл весом сотни мегабайт. | Согласовать LFS и правила доставки данных, а не увеличивать лимит вслепую. |
#Пошаговая диагностика и решение
- Сохраните полный текст отказа и проверьте адрес сервераОткройте проект в VS Code, выберите «Терминал» → «Создать терминал» и введите
git remote -vиgit status -sb. Скопируйте строки ошибки из предыдущегоgit push, особенно имя файла, размер, ограничение иremote rejected. Не выкладывайте в открытый доступ адреса внутренних систем или токены. Если сервер сообщает protected branch, запрет подписи или отсутствие прав, размер файла может быть ни при чём. Перед остальными командами выполнитеgit --version: в ответ должна появиться установленная версия Git. Если терминал сообщает, чтоgitне найден, проверьте установку Git и доступность команды в этом терминале; не продолжайте операции наугад. - Сверьте правила хранилища с администраторомОткройте веб-интерфейс своего Git-сервера в браузере и страницу настроек проекта, если у вас есть доступ. Поскольку конкретные пункты интерфейса GitLab и внутренних систем различаются, запросите у администратора точный порог максимального файла и поддержку Git LFS. Не отправляйте один и тот же файл повторно и не меняйте серверные ограничения самостоятельно.
- Найдите файл в текущем дереве и историиВ терминале Git выполните
git ls-files -- путь/к/файлу, заменив путь из ошибки. Если вывод есть, файл отслеживается сейчас; если нет, просмотритеgit log --all --oneline -- путь/к/файлу. Это позволяет понять, сохранился ли объект в старом коммите. Если сервер назвал SHA объекта вместо пути, передайте его специалисту для точной идентификации. - Если файл только подготовлен к коммиту, уберите его из индексаПрименяйте только когда большой файл ещё НЕ закоммичен. Проверьте
git status; если файл отмечен как новый в подготовленных к коммиту, выполнитеgit restore --staged -- путь/к/файлу. Рабочий файл останется на диске, но исчезнет из будущего коммита. Для файла, который был уже закоммичен, эта команда НЕ удалит его из истории; переходите к следующему шагу. - Если файл попал только в последний локальный коммит, не опубликованный нигдеУбедитесь у коллег, что этот коммит не ушёл на другие серверы и на нём никто не основывает ветку. Сделайте отдельную резервную копию проекта, проверьте
git log -1 --onelineиgit show --stat HEAD. При подтверждении можно удалить путь только из индекса черезgit rm --cached -- путь/к/файлу, затем сделатьgit commit --amend --no-edit. Исходный файл останется в рабочей папке, однако SHA последнего коммита изменится. Не применяйте такой приём для merge-коммита, общей ветки или файла в более ранних коммитах. - При большом файле в нескольких коммитах остановите автоматический откатЕсли удаление затрагивает более раннюю историю, не пытайтесь скрыть объект отдельным новым коммитом или запускать
git reset --hard. Подготовьте перечень локальных коммитов, пути и размеры для сопровождающего репозитория. Исправление может потребовать переписать неопубликованную ветку, но это отдельная согласованная миграция с сохранением копий и проверкой всех ссылок. - Выберите для больших файлов LFS или внешнее хранилищеЕсли сервер поддерживает LFS, откройте его официальную документацию и согласуйте с командой правила отслеживания нужного расширения и доступное хранилище. Важно: установка Git LFS для будущих файлов не удаляет уже созданные большие объекты из истории. Для логов, архивов сборки и резервных копий обычно безопаснее оставить их в специализированном хранилище, не в Git.
- Повторите отправку только после проверки диапазона коммитовУбедитесь, что целевая ветка и её адрес верны, сохраните резервную копию, затем снова выполните обычный
git pushбез--force. Если сервер сообщает тот же объект, значит он всё ещё есть среди отправляемых коммитов; сохраните текст и обратитесь к администратору. Успех подтверждается появлением ветки и её коммитов в веб-интерфейсе.
#Команды для проверки и исправления
git remote -vgit status -sbgit log -1 --oneline-- ограничивает обработку путём, --all просматривает известные ссылки.git ls-files -- путь/к/файлуgit log --all --oneline -- путь/к/файлуgit restore --staged -- путь/к/файлуКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
git rm --cached -- путь/к/файлуgit commit --amend --no-editЭта команда может привести к потере данных или существенным изменениям. Проверьте параметры, резервную копию и возможность отката.
#Как проверить результат и что делать, если не помогло
После исправления обычный git push проходит без сообщения о лимите, а сервер показывает ожидаемый новый коммит. Если файл всё ещё упоминается, значит он находится в другом коммите диапазона или лимит касается других объектов. Сохраните push-вывод для сопровождающего сервера; не повышайте лимиты без расчёта места.