Краткий ответ

Риск создаёт параметр dismiss_stale_approvals: false: после изменения кода ранее выданные согласования продолжают действовать, хотя проверенный набор изменений уже изменился. Нужно автоматически отзывать устаревшие согласования при каждом новом коммите и требовать повторной независимой проверки.

Иначе автор может внести существенное изменение после ревью, а система всё равно разрешит слияние на основании одобрения старой версии.

Исторический контекст

Контроль защищённых веток появился как процессный ответ на риск попадания непроверенных изменений в общую интеграционную ветку. Одного правила «обязательно сделать ревью» недостаточно: важно гарантировать, что согласование относится именно к той версии изменений, которая будет объединена.

Механизм отзыва устаревших согласований закрывает класс ошибок, возникающих при последовательности «проверка — изменение — слияние». Он дополняет ревью автоматическими проверками и не позволяет процессу зависеть только от дисциплины участников.

Постановка проблемы

Pull request первоначально прошёл проверку двух рецензентов. Затем автор изменил код по замечаниям или добавил новую логику, но старые согласования остались действительными.

В результате защищённая ветка может принять изменения, которые никто из обязательных рецензентов не видел. Особенно опасно это для исправлений в платёжной логике, авторизации, миграциях данных и конфигурации поставки: небольшой новый коммит способен изменить риск профиля всего изменения.

Подробное решение

Нужно включить отзыв устаревших согласований после изменения проверяемого набора файлов. После нового коммита pull request должен снова перейти в состояние ожидания требуемого числа согласований, а автоматические проверки должны выполняться для актуального состояния ветки.

Типовой процесс выглядит так:

Автор открывает pull request.
CI проверяет текущий коммит.
Независимые рецензенты согласуют именно этот набор изменений.
Новый коммит отзывает прежние согласования.
CI и ревью запускаются повторно.
Слияние разрешается только после успешных проверок и новых согласований.

Важно определить, какие изменения делают согласование устаревшим. Самый безопасный вариант — отзывать его при любом новом коммите в pull request. Более точечные правила, например отзыв только при изменении отдельных файлов, уменьшают задержки, но требуют надёжно определить границы влияния; ошибка в таком правиле может вернуть исходный риск.

Этот контроль не заменяет ревью. Он не проверяет качество самого согласования, не обнаруживает дефекты, которые не покрыты тестами, и не защищает от формального одобрения без анализа. Поэтому его обычно сочетают с обязательными CI-проверками, запретом прямой записи в основную ветку и разделением авторства и ревью для критичных изменений.

У контроля есть компромисс: после каждого исправления автору и рецензентам приходится повторять часть работы. Это увеличивает время слияния, но делает связь между одобрением и фактическим кодом явной. Для небольших исправлений задержку можно снизить быстрым CI и ограничением размера pull request, а не сохранением потенциально неверных согласований.

Минимальная политика должна выглядеть так:

protected_branch:
  name: main
  require_pull_request: true
  required_approvals: 2
  dismiss_stale_approvals: true
  allow_direct_push: false

Параметр dismiss_stale_approvals: true здесь обозначает требование повторного согласования после изменения pull request; конкретное имя настройки зависит от используемой платформы.

Ситуация из практики

Команда разрабатывала сервис управления доступом. Pull request получил два согласования, после чего автор добавил коммит, меняющий проверку роли для административного endpoint. Из-за сохранения старых согласований изменение попало в основную ветку без повторной проверки.

Рассматривались три варианта. Полностью отказаться от обязательного ревью было быстро, но увеличивало риск. Назначать нового рецензента вручную после каждого коммита было гибче, но зависело от памяти и дисциплины команды. Автоматически отзывать старые согласования было менее удобно, зато правило применялось одинаково и не зависело от человека.

Выбрали третий вариант, дополнив его обязательными проверками CI и запретом прямых изменений в основной ветке. После этого изменение роли снова потребовало двух согласований, а риск обхода ревью исчез на уровне процесса. Цена решения — дополнительный цикл проверки после каждого существенного исправления; её компенсировали небольшими pull request и быстрыми автоматическими проверками.

Что кандидаты часто упускают

Достаточно ли отзывать согласования только при изменении исходного кода?

Нет, это зависит от области действия изменения. Изменение конфигурации, схемы данных, инфраструктурного файла или тестов также может менять поведение поставки и риск релиза. Безопасное базовое правило — считать устаревшим согласование после любого нового коммита, а исключения вводить только при доказанной независимости файлов.

Почему успешный CI не заменяет повторное ревью?

CI проверяет заранее автоматизированные свойства: сборку, тесты, статический анализ и другие формальные условия. Он не обязательно оценивает соответствие бизнес-логике, архитектурные последствия или безопасность нового сценария. Поэтому после изменения кода нужны и повторные автоматические проверки, и согласование человека, если политика требует человеческого ревью.

Можно ли разрешить автору повторно подтвердить собственное изменение вместо независимого рецензента?

Самоподтверждение не даёт независимого контроля и особенно рискованно для критичных компонентов. Исключение допустимо только для явно определённых низкорисковых изменений, если это согласовано политикой команды. Для доступа, финансовых операций и production-конфигурации следует сохранять независимое число согласований и, при необходимости, требовать участия владельца компонента.