Как запретить push файлов по путям через GitHub push ruleset

Как выбирать и проверять path-pattern

Restrict file paths в push ruleset работает на стороне GitHub и блокирует push, затрагивающий заданные пути. Это другой инструмент, чем `.gitignore`: ignore помогает не добавить файл локально, но не запрещает серверу принять уже отслеживаемый путь. Начинайте с точного каталога или имени файла и тестируйте fnmatch-шаблон на отдельной ветке. Слишком широкая маска легко заденет соседние каталоги, поэтому после отрицательного теста обязательно сделайте положительный — обычный разрешённый путь должен по-прежнему пушиться.

Совет: Начинайте с узкого path-pattern и только после теста расширяйте маску — так меньше риск заблокировать соседние каталоги.

Что сделать по шагам

1. Откройте Settings → Rules → Rulesets и создайте push ruleset.
2. Задайте область и enforcement.
3. Добавьте Restrict file paths и запрещённые patterns.
4. Проверьте тестовым файлом до строгого enforcement.
5. Добавляйте bypass только доверенной автоматизации, если он действительно нужен.

Предупреждение: Не пытайтесь заменить .gitignore серверным ruleset или наоборот — задачи разные.

Что важно учесть в текущей реализации

Restrict file paths в push ruleset работает на сервере и блокирует push, даже если разработчик не добавил нужный путь в `.gitignore`. GitHub поддерживает `fnmatch`-шаблоны: можно закрыть целый каталог вроде `test/demo/**/*` или конкретный файл. Для Restrict file paths доступны allowed exceptions, поэтому широкий запрет можно дополнить точечными разрешениями. Перед Active enforcement протестируйте минимум три случая: запрещённый путь, соседний разрешённый путь и одно исключение. Не используйте ruleset вместо `.gitignore`: ignore предотвращает случайное добавление локальных файлов, а push rule — серверный контроль уже сформированного commit. Для секретов лучше Secret Scanning/Push Protection, а не маска по имени файла.

Важно: Слишком широкий шаблон может заблокировать легитимный соседний путь.

Проверка результата и крайние случаи

GitHub использует fnmatch-подобные patterns, поэтому тестируйте реальные имена путей, включая вложенность и похожие каталоги. Если policy требует исключения, используйте поддерживаемый allowed exception для конкретного пути или актора, а не расширяйте общий шаблон. Помните, что push rules могут распространяться на fork network в зависимости от конфигурации: это стоит учитывать для репозиториев с активной моделью форков. После включения сохраните один успешный и один отклонённый тест — так команде проще понять реальную границу правила.

Контрольный список

• Pattern проверен на запрещённом пути.
• Похожий разрешённый путь всё ещё пушится.
• Исключения сделаны точечно, если они действительно нужны.
• Правило не используется вместо .gitignore для другой задачи.

Финальная проверка

В описании ruleset укажите назначение каждого path-pattern; это помогает отличить security restriction от случайного запрета, который позже кто-то обойдёт слишком широким bypass.

Ожидаемый результат

Пуш запрещённого path должен отклоняться, а соседний разрешённый файл — проходить тем же пользователем при том же ruleset.

Последняя проверка перед завершением

Если ruleset используется для секретных или генерируемых каталогов, отдельно проверьте действия CI, которые пушат изменения обратно в репозиторий, чтобы не создать скрытый конфликт автоматизации.

Что учитывать

Restrict file paths в push ruleset работает на сервере и блокирует push, даже если разработчик не добавил нужный путь в `.gitignore`. GitHub поддерживает `fnmatch`-шаблоны: можно закрыть целый каталог вроде `test/demo/**/*` или конкретный файл. Для Restrict file paths доступны allowed exceptions, поэтому широкий запрет можно дополнить точечными разрешениями. Перед Active enforcement протестируйте минимум три случая: запрещённый путь, соседний разрешённый путь и одно исключение. Не используйте…

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• Available rules for rulesets
• About rulesets