Компьютеры · Инструкция
Как запретить расширения файлов через GitHub push ruleset
Запрет расширений на уровне GitHub работает для всех contributors и не зависит от их локального .gitignore. Сервер отвергнет push с запрещённым типом файла, поэтому правило удобно для общей политики репозитория.
Короткий ответ
Как запретить push выбранных расширений через GitHub ruleset, когда лучше использовать путь, а когда вынести бинарники в Git LFS.
Когда запрет расширений подходит, а когда нет
Запрет расширений удобен, когда политика относится ко всему репозиторию: например, выбранный тип бинарников нигде не должен попадать в Git. Если один такой файл всё же допустим в отдельном каталоге, extension-rule становится слишком грубым — тогда лучше ограничивать путь. До enforcement проверьте не только ручной commit, но и CI/release automation: генератор может добавлять запрещённое расширение автоматически. Для больших бинарных артефактов отдельно решите, должны ли они храниться через Git LFS, Releases или другое хранилище, а не просто блокироваться.
Совет: Проверьте CI и release automation: нежелательное расширение может появляться не у разработчика, а у бота.
Что сделать по шагам
- Создайте или откройте push ruleset.
- Добавьте Restrict file extensions.
- Внесите только расширения с понятной политикой хранения.
- Протестируйте один запрещённый и один разрешённый файл.
- После теста включите enforcement и документируйте альтернативное хранилище.
Предупреждение: Не запрещайте расширение только потому, что оно бинарное, если проект реально его использует.
Что важно учесть в текущей реализации
Restrict file extensions полезен, когда определённый тип файлов не должен попадать в Git ни в одной папке. GitHub позволяет перечислить до 200 ограничений, каждое длиной до 200 символов. Важный нюанс: для extension-rule нет allowed exception на отдельный файл; если нужен редкий разрешённый `.jar` или другой тип, GitHub рекомендует описать запрет через Restrict file paths и добавить исключение. До включения проверьте реальные артефакты проекта и CI — release job может коммитить файл, который разработчики вручную не добавляют. Если крупные бинарники нужно версионировать, Git LFS решает другую задачу: хранит содержимое иначе, а не просто запрещает push.
Важно: Проверьте, не пушит ли CI такой файл в процессе релиза.
Проверка результата и крайние случаи
У extension-rule есть важное ограничение: GitHub документирует лимит на число записей и не предоставляет allowed exception для отдельного файла так же, как для некоторых path rules. Если нужен единственный допустимый `.zip` или `.dll` в конкретном месте, перенесите логику в Restrict file paths или измените модель хранения. Для больших бинарников Git LFS решает другую задачу — хранение объектов вне обычной Git-истории — и не является автоматической заменой security policy. Тестируйте расширение в разных регистрах и на файлах, создаваемых автоматизацией.
Контрольный список
- Запрещённое расширение отклоняется.
- Разрешённые типы файлов продолжают пушиться.
- CI и release automation проверены отдельно.
- Для единичного исключения рассмотрен path-rule вместо глобального extension-rule.
Финальная проверка
Сообщите разработчикам, куда складывать запрещённый тип файла вместо Git; без рабочего альтернативного пути правило будет провоцировать архивы, переименования и другие обходные решения.
Что учитывать
Restrict file extensions полезен, когда определённый тип файлов не должен попадать в Git ни в одной папке. GitHub позволяет перечислить до 200 ограничений, каждое длиной до 200 символов. Важный нюанс: для extension-rule нет allowed exception на отдельный файл; если нужен редкий разрешённый `.jar` или другой тип, GitHub рекомендует описать запрет через Restrict file paths и добавить исключение. До включения проверьте реальные артефакты проекта и CI — release job может коммитить файл, который…
Источники и проверка
Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.