Компьютеры · Инструкция
Как ограничить размер файлов через GitHub push ruleset
Ограничение размера файла предотвращает попадание тяжёлых объектов в обычную Git-историю. Серверное правило надёжнее устной договорённости «не коммитить большие архивы», но порог нужно выбирать по данным проекта.
Короткий ответ
Как задать максимальный размер отдельного файла в GitHub push ruleset, протестировать порог и настроить allowed exceptions без очистки истории.
Как выбрать лимит размера файла без поломки репозитория
Ограничение размера файла в push ruleset защищает репозиторий от новых тяжёлых объектов, но порог нельзя выбирать случайно. Сначала найдите крупнейшие нормальные файлы текущего проекта: модели, fixtures, тестовые данные, документацию. Лимит должен пропускать их с разумным запасом и одновременно останавливать архивы или медиаданные, которые не должны попадать в Git. Помните, что правило проверяет новые push и не вычищает уже существующую историю; старый большой blob требует отдельной процедуры очистки истории, если его действительно нужно удалить.
Совет: Соберите список крупнейших нормальных файлов проекта и ставьте лимит выше их размера с небольшим запасом.
Что сделать по шагам
- Соберите размеры крупнейших текущих файлов.
- Откройте push ruleset и включите Restrict file size.
- Задайте порог выше нормальных исходников и ниже нежелательных архивов.
- Попробуйте push чуть ниже и чуть выше порога.
- Настройте альтернативное хранилище для реально крупных файлов.
Предупреждение: Не выбирайте лимит вслепую — сначала измерьте существующий репозиторий.
Что важно учесть в текущей реализации
Restrict file size задаёт лимит для отдельного файла, а не для суммарного размера commit. GitHub позволяет добавлять allowed exceptions по пути, поэтому, например, конкретный wrapper или fixture может быть больше общего порога. Выбирайте лимит после инвентаризации репозитория: посмотрите крупнейшие нормальные исходники и только затем ставьте значение выше них. В тестовом PR попробуйте файл чуть ниже и чуть выше порога. Помните, что новое правило не уменьшает уже существующую историю Git: удаление большого файла новым commit тоже не удаляет старый blob. Для исторически раздутого репозитория требуется отдельная очистка истории, а для будущих крупных артефактов — Git LFS, Releases или CI artifact storage.
Важно: Если файл уже в истории, новое правило его оттуда не удалит.
Проверка результата и крайние случаи
Правило относится к размеру отдельного файла, а не к суммарному размеру commit. Поэтому тест должен включать два файла: один немного ниже порога и один выше. Если крупный объект действительно нужен, используйте allowed exception там, где это поддерживается, либо перенесите его в Git LFS/релизные assets по правилам проекта. Новый ruleset не удалит уже закоммиченный большой blob и не уменьшит размер существующей истории. Для этого нужен отдельный history rewrite с планом координации команды, а не изменение push-limit.
Контрольный список
- Порог основан на реальных файлах проекта.
- Файл ниже лимита проходит, выше — отклоняется.
- Крупным легитимным объектам назначено подходящее хранилище.
- Понятно, что existing Git history правило не очищает.
Финальная проверка
Задокументируйте выбранный лимит и место для файлов крупнее него, чтобы правило не превращалось в неожиданную ошибку при следующем добавлении fixture, модели или релизного артефакта.
Что учитывать
Restrict file size задаёт лимит для отдельного файла, а не для суммарного размера commit. GitHub позволяет добавлять allowed exceptions по пути, поэтому, например, конкретный wrapper или fixture может быть больше общего порога. Выбирайте лимит после инвентаризации репозитория: посмотрите крупнейшие нормальные исходники и только затем ставьте значение выше них. В тестовом PR попробуйте файл чуть ниже и чуть выше порога. Помните, что новое правило не уменьшает уже существующую историю Git…
Источники и проверка
Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.