GitHub разрешил Copilot ставить approve на pull request
Approve от ИИ засчитывается в merge-требования, если администратор это включит.
GitHub 1 сентября сообщил, что Copilot code review научился ставить на pull request настоящий approve, и такое одобрение может засчитываться в обязательные approvals репозитория. Для команд, у которых merge закрыт правилом «нужно одно одобрение», это означает, что при включённой настройке код сможет доехать до main без единого человека.
Функция вышла в public preview для тарифов Copilot Pro, Pro+, Max, Business и Enterprise. По умолчанию она выключена: администраторам придётся включить её явно, и сделать это можно на уровне enterprise, организации или отдельного репозитория. GitHub при этом ничего не говорит о региональной доступности, поэтому для аккаунтов из России действуют те же условия, что и у самого Copilot: нужна платная подписка, а вопрос её оплаты публикация не затрагивает.
Ключевые выводы
- Каждый обзор Copilot теперь содержит вердикт «готов к одобрению или нет»; сам по себе вердикт в merge-требования не засчитывается.
- Если администратор включит настройку, Copilot будет ставить настоящий approve, и он считается наравне с одобрением человека.
- Настройка выключена по умолчанию; управляется на уровне enterprise, организации и репозитория.
- В репозитории можно ограничить approve списком путей: за пределами списка Copilot только комментирует.
- Новый коммит после approve автоматически снимает одобрение, как и у обычных ревьюеров.
Вердикт и approve теперь разные вещи
До этого релиза Copilot code review оставлял замечания и общий комментарий, а решение «можно ли мержить» оставалось за людьми. Теперь в каждом обзоре появился approval assessment: Copilot пишет, считает ли он pull request готовым к одобрению. GitHub прямо оговаривает, что «одна только оценка готовности не засчитывается в merge-требования» (здесь и далее перевод редакции). Это информационный сигнал, и он появляется у всех, кто пользуется Copilot code review, без дополнительных настроек.
Второй уровень включается отдельно. Если администратор разрешил Copilot одобрять, то при положительной оценке Copilot отправляет обычный approve через штатный механизм ревью. Такой approve участвует в правилах защиты веток: если branch protection требует одно одобрение, оно будет выполнено. По нашей оценке, именно эта деталь и есть новость: Copilot code review теперь формально закрывает требование ревью.
Механика отзыва одобрения не изменилась. Как и у ревьюера-человека, approve Copilot снимается, когда в ветку приходит новый коммит. Поэтому сценарий «получил одобрение от бота, потом дописал что угодно и смержил» не работает: после каждого пуша Copilot будет пересматривать изменения заново.
Три уровня контроля и фильтр по путям
GitHub построил включение по каскаду. Администратор enterprise может запретить функцию всем организациям сразу. Администратор организации включает её выборочно для репозиториев. Администратор репозитория включает или выключает approve у себя и, что важнее, может задать список путей, к которым Copilot имеет право применять approve.
На практике это значит, что разумная конфигурация выглядит не как «Copilot одобряет всё», а как «Copilot одобряет документацию, тесты и локализацию, а к src/auth/ и инфраструктурному коду не прикасается». Если pull request задевает файлы вне списка, Copilot по-прежнему оставит замечания, но approve не поставит.
Что GitHub не сказал: по каким критериям Copilot принимает решение о готовности, как часто он ошибается и есть ли у компании собственные замеры доли ложных одобрений. Публикация описывает только механику и настройки. Пока функция в public preview, GitHub оставляет за собой право менять её поведение.
Что проверить у себя сегодня
- Убедиться, что в организации функция по-прежнему выключена: она отключена по умолчанию, но проверить настройки Copilot в разделе организации стоит, особенно если администраторов несколько.
- Если approve от Copilot нужен, включать его точечно: сначала в репозиториях без критичного кода и с фильтром по путям, а не на всю организацию.
- Пересмотреть правила защиты веток. Если merge требует ровно одно одобрение и Copilot попадает в число допустимых ревьюеров, стоит поднять требование до двух или добавить в CODEOWNERS обязательного человека для чувствительных каталогов.
- Договориться в команде, что approve Copilot не заменяет ревью человека для изменений в аутентификации, платежах, миграциях и CI-конфигурации.
Approve от Copilot снимается новым коммитом: как только в ветку приходит изменение, одобрение отзывается, и Copilot пересматривает pull request заново. Про истечение одобрения по времени GitHub ничего не пишет.
Почему это шаг дальше, чем автообзор
Автоматический обзор Copilot существует давно, и у многих команд он включён на каждый pull request. Но роль у него была совещательная: комментарии можно проигнорировать, а merge всё равно требовал одобрения человека. С 1 сентября GitHub позволяет передать ИИ часть формальной ответственности за merge-gate. Для маленьких команд и соло-проектов это удобно: правило «одно одобрение» перестаёт блокировать работу, когда второго человека просто нет. Для больших организаций это ещё один пункт в аудите доступов.
Следить стоит за двумя вещами: когда функция выйдет из public preview и появятся ли у GitHub публичные данные о точности вердиктов. Редакция проверит, изменятся ли значения по умолчанию к стабильному релизу.
Источник: Changelog GitHub: Copilot code review can now approve pull requests
Изображение на обложке: GitHub
