Как разрешить force push в защищённую ветку GitHub только отдельным участникам

Почему force push должен оставаться узким исключением

Force push переписывает историю ветки, поэтому разрешать его на protected branch стоит только для редкого, заранее определённого процесса. GitHub позволяет оставить общий запрет и дать исключение выбранным пользователям или teams — это безопаснее, чем открывать force push всем с write-доступом. Перед тестом сохраните текущий commit SHA и предупредите участников: после переписывания их локальные ветки могут расходиться с remote. Если задача решается обычным revert или новым commit, force push обычно не нужен.

Совет: Сохраните текущий SHA protected branch перед force push, чтобы при необходимости быстро найти прежнее состояние.

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

1. Откройте Settings и правило нужной ветки.
2. Найдите Allow force pushes и доступные варианты акторов.
3. Разрешите force push только необходимому пользователю, team или app.
4. Проверьте настройку на тестовой ветке или репозитории.
5. Задокументируйте допустимые случаи и recovery-процедуру.

Предупреждение: Не включайте force push на main как способ регулярно «чистить» историю.

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

GitHub по умолчанию блокирует force push в protected branch. Если исключение действительно нужно, настройка позволяет разрешить его либо всем с write-доступом, либо только выбранным людям и teams. Для основной ветки второй вариант безопаснее: force push переписывает историю и может сделать локальные ветки коллег несовместимыми с remote. Перед операцией сохраните текущий SHA ветки и сообщите команде, что будет history rewrite. После force push проверьте branch protection, открытые PR и CI: некоторые проверки привязаны к предыдущим commit SHA. Если регулярный процесс требует постоянно переписывать main, лучше пересмотреть сам workflow, чем превращать аварийное исключение в стандартную практику.

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

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

После force push сравните новый head с сохранённым SHA и сразу проверьте открытые pull requests и CI: переписанная база может изменить diff, повторно запустить проверки или потребовать rebase у участников. Исключение лучше выдавать конкретному человеку или team, а не «всем с write». Для восстановимости держите ссылку на старый commit до завершения проверки. Если команда часто переписывает main ради аккуратной истории, это сигнал пересмотреть workflow: squash/rebase при merge обычно решает задачу без регулярного force push защищённой ветки.

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

• Сохранён исходный commit SHA.
• Force push разрешён только выбранным акторам.
• Пользователь без исключения получает отказ.
• После rewrite проверены PR и CI.

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

Если исключение больше не нужно после миграции или разового history rewrite, удалите его из защиты ветки; временное право не должно оставаться постоянным после завершения задачи.

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

Проверьте force push разрешённым и обычным участником: только выбранный актор должен переписать protected branch, остальные — получить отказ.

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

После завершения разовой операции снимите исключение, если force push больше не требуется: разрешение не должно оставаться частью постоянной политики ветки без актуальной причины.

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

Force push переписывает историю ветки, поэтому разрешать его на protected branch стоит только для редкого, заранее определённого процесса. GitHub позволяет оставить общий запрет и дать исключение выбранным пользователям или teams — это безопаснее, чем открывать force push всем с write-доступом. Перед тестом сохраните текущий commit SHA и предупредите участников: после переписывания их локальные ветки могут расходиться с remote. Если задача решается обычным revert или новым commit, force push…

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

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

• About protected branches