Компьютеры · Инструкция
GitHub: как сбрасывать устаревшие approvals после новых commits
GitHub: как сбрасывать устаревшие approvals после новых commits — для защищённой ветки это делает настройка Dismiss stale pull request approvals when new commits are pushed.
Короткий ответ
В branch protection или ruleset включите `Dismiss stale pull request approvals when new commits are pushed`. Тогда если diff PR изменился после approval, GitHub снимет устаревшее одобрение и потребует новое.
Когда approval становится stale
GitHub считает одобрение относящимся к конкретному состоянию diff. Если после review автор пушит новые изменения, нажимает Update branch или merge-base меняется из-за связанных изменений в base branch, approval может быть снято как устаревшее. Это защищает от сценария, когда важный код добавили после просмотра. Настройка строже, чем просто требование одного review, потому что проверяется актуальность одобрения относительно текущего diff.
Совет: Проверьте правило на тестовом PR до включения для всех release-веток.
Как включить правило для защищённой ветки
- Откройте Settings репозитория и раздел Branches либо Rulesets в зависимости от используемой модели защиты.
- Выберите правило для целевой ветки, например `main`, и включите обязательный pull request review.
- Активируйте `Dismiss stale pull request approvals when new commits are pushed`.
- Если нужно, ограничьте право вручную dismiss review определёнными людьми или командами.
- Создайте тестовый PR, получите approval, затем измените diff новым commit и убедитесь, что approval действительно сброшено.
Чем это отличается от «approval последнего push»
GitHub отдельно предлагает правило, по которому самый свежий reviewable push должен быть одобрен кем-то, кроме автора этого push. Оно может сохранять старые reviews и требовать лишь актуальное подтверждение последнего изменения. Dismiss stale approvals строже: изменившийся diff лишает старое одобрение силы. GitHub отмечает, что для защиты от «hijacked» PR вариант со сбросом stale approvals безопаснее, хотя и создаёт больше повторных review.
Предупреждение: Автоматические боты, которые пушат formatting changes, тоже могут сбрасывать approvals.
Перед включением на большой команде
- оценить частоту автоматических Update branch;
- объяснить, почему reviews будут исчезать;
- проверить ботов, которые меняют branch после approval;
- решить, нужен ли ещё отдельный last-push approval.
Чем это отличается от нового одобрения
Dismiss stale approvals аннулирует прежнее одобрение после изменения diff, поэтому reviewer должен оценить обновлённый вариант снова. Отдельная настройка GitHub про approval самого свежего reviewable push решает другую задачу и не является полным эквивалентом сброса всех устаревших approvals.
Как избежать формального одобрения старого diff
При включённом dismiss stale approvals новое изменение diff сбрасывает старое approve, поэтому merge нельзя провести только на основании проверки предыдущей версии. Это особенно полезно, когда автор после ревью вносит функциональные изменения. Но правило увеличивает число повторных ревью; для больших команд заранее определите, какие изменения требуют полного пересмотра и какие ветки действительно должны находиться под таким branch protection.
Пример после небольшого исправления CI
PR уже получил два approvals, затем автор добавил один commit, исправляющий тест. При включённом stale-dismiss GitHub рассматривает diff как изменившийся и старые approvals больше не дают merge. Reviewer должен подтвердить обновлённую версию. Это намеренное поведение, а не потеря review из-за бага.
Важно: Если процесс требует меньшего friction, сравните stale-dismiss с отдельным правилом approval последнего push.
Что учитывать
Условия меняются. Страница отражает состояние на 2026-09-23; при расхождении с официальной документацией приоритет у первоисточника.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. About protected branches). Пример и формулировки — редакция N1RO на 2026-09-23.