Запись архива

GitHub расширил настройки Copilot Code Review на всех планах

GitHub сделал персональные настройки Copilot Code Review доступными на всех планах, включая Business и Enterprise, и добавил корпоративный дефолт для уровня анализа.

Страница настроек GitHub Copilot Code Review с выбором уровня анализа
Страница настроек GitHub Copilot Code Review с выбором уровня анализа
Изображение из исходного материала

GitHub объявил о расширении настроек Copilot Code Review. С 23 сентября 2026 года персональная страница конфигурации доступна на всех планах Copilot, включая Copilot Business и Copilot Enterprise. Одновременно авторизованные администраторы Enterprise получили возможность задать уровень анализа по умолчанию для организаций и репозиториев, которые от них наследуют настройки.

Обновление касается именно управления автоматическими и ручными ревью. GitHub не сообщает о запуске новой модели или изменении принципов работы Copilot Code Review: нововведение связано с тем, где задаются параметры проверки и кто может устанавливать их на уровне компании.

Персональные настройки вынесли на отдельную страницу

Раньше настройки Copilot Code Review находились на странице «Copilot features» и были доступны только пользователям Copilot Pro, Pro+ и Max. Там можно было задать один общий параметр для автоматических проверок.

Теперь в профиле GitHub появился отдельный раздел Copilot → Code review. По данным GitHub, он доступен пользователям всех планов Copilot. На этой странице можно выбрать уровень effort — то есть степень усилий, которую Copilot должен применять при проверке:

  • Lite;
  • Balanced;
  • GitHub default.

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

Это позволяет не привязывать все проверки к одному режиму. Например, для небольшого изменения можно оставить Lite, а для изменения, затрагивающего критический код, перед ручным запросом выбрать более тщательную конфигурацию. При этом GitHub не раскрывает в changelog количественные различия между режимами: неизвестно, сколько дополнительных файлов или контекста анализирует каждый уровень и как это влияет на лимиты.

Настройки для черновиков и новых push

В предыдущей конфигурации не было отдельных элементов управления для черновиков pull request и новых push-коммитов. GitHub указывает, что новая страница расширяет персональную настройку автоматических ревью и позволяет учитывать эти сценарии раздельно.

Для команды это имеет практическое значение. Черновик pull request часто используется для ранней обратной связи, когда разработчик еще меняет архитектуру или собирает первоначальный вариант решения. Проверка после нового push, напротив, может быть нужна уже для контроля конкретной итерации изменений. Единый режим не всегда подходит обоим случаям.

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

Enterprise может задать общий уровень проверки

Новое корпоративное управление предназначено для авторизованных администраторов Enterprise. Они могут установить один дефолтный уровень effort для enterprise-окружения: Lite, Balanced или GitHub default.

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

Такой подход подходит компаниям, которым нужен единый стартовый режим для новых проектов. Администратор может выбрать общий вариант, а команды, работающие с более чувствительным или сложным кодом, — переопределить его на уровне организации либо репозитория. GitHub не утверждает, что корпоративный параметр заменяет существующие политики code review или правила защиты веток: в опубликованном сообщении речь идет только о настройке effort для Copilot.

Что изменится для пользователей Business и Enterprise

Для пользователей Copilot Business и Copilot Enterprise ключевое изменение — появление персональной страницы code review. Ранее доступ к аналогичным настройкам был ограничен другими планами, поэтому корпоративные пользователи не могли централизованно управлять личным уровнем анализа через этот интерфейс.

Теперь разработчик может один раз выбрать предпочтительный режим для обычных запросов, а при необходимости изменить его для отдельного pull request. Командам это сокращает число повторяющихся действий, но не отменяет проверку результатов: уровень effort определяет конфигурацию работы Copilot, а не гарантирует обнаружение всех ошибок.

Для Enterprise-администраторов важнее наследование. Общий дефолт можно использовать как базовый стандарт, а затем отдельно настроить проекты с повышенными требованиями. Однако до внедрения политики стоит выяснить, какие организации и репозитории уже содержат собственные переопределения. Иначе фактическое поведение Copilot может отличаться от значения, установленного на верхнем уровне.

Что проверить после обновления

Пользователям следует открыть профиль GitHub и перейти в Copilot → Code review. Там стоит проверить выбранный effort и параметры автоматического запуска для pull request, черновиков и новых push-коммитов. Для ручной проверки значение можно уточнить непосредственно в секции Reviewers перед отправкой запроса.

Администраторам Enterprise необходимо отдельно проверить:

  • установлен ли корпоративный дефолт;
  • какие организации и репозитории наследуют его;
  • где действуют локальные переопределения;
  • соответствует ли выбранный режим внутренним требованиям к проверке кода.

В changelog GitHub описывает настройки интерфейса и наследование, но не приводит независимое сравнение Lite, Balanced и GitHub default по качеству, скорости или расходу лимитов. Поэтому эти режимы не следует трактовать как формальную шкалу надежности без собственных тестов на типичных pull request команды.

Первичный источник обновления — сообщение GitHub Changelog. Общий контекст по продукту доступен на странице GitHub Copilot, а справочная документация собрана в разделе GitHub Docs о Copilot.

Источники