Как проверить локальные изменения Copilot в Visual Studio

Проверено 13 сентября 2026 года. Официальная инструкция требует Visual Studio 17.14 или новее. Команда называется Review changes with Copilot и находится в окне Git Changes. После анализа появляется ссылка с числом комментариев; при отсутствии замечаний интерфейс сообщает Copilot did not comment on any files.

Основные первоисточники: использование Copilot Code Review, настройка Copilot Code Review и MCP для Copilot в репозитории. Для этого материала использованы только названия функций и поведение, прямо описанные GitHub. Тарифы и цены не приводятся: они не нужны для выполнения процедуры и могут меняться.

Перед началом убедитесь, что у вас есть административные права для нужного уровня — репозитория или организации. Сделайте снимок текущей конфигурации: запишите значение переключателей, имя ruleset, его targets и обязательные checks. Такой baseline позволяет отличить эффект новой настройки от уже существующей политики и быстро вернуть рабочее состояние.

Пошаговая настройка

1. Проверьте, что используется Visual Studio 17.14 или новее и Copilot доступен в текущей учётной записи. Версию сверяйте в установленной среде, а не по памяти.
2. Откройте решение и окно Git Changes.
3. Просмотрите список изменённых файлов и удалите случайные бинарные файлы, секреты и сгенерированный шум до отправки данных на review.
4. Нажмите Review changes with Copilot в окне Git Changes.
5. После завершения откройте ссылку с количеством review comments. Если показано сообщение Copilot did not comment on any files., это означает лишь отсутствие комментариев, а не доказанную корректность.
6. Разберите каждый комментарий по связанному файлу и строке. Исправьте код либо письменно зафиксируйте причину отклонения.
7. Чтобы закрыть отдельный комментарий, используйте стрелку вниз в правом верхнем углу его блока. Чтобы удалить все комментарии, нажмите X рядом со ссылкой review.
8. Запустите тесты и статический анализ, затем при необходимости повторите локальный review перед commit.

После сохранения не переходите сразу к массовому включению. Откройте страницу ruleset или Code review повторно и убедитесь, что значение сохранилось. Затем проверяйте поведение на отдельной ветке и безопасном PR. В описании PR укажите цель теста, ожидаемый эффект и человека, который подтвердит результат. Это превращает разовую настройку в проверяемую процедуру.

Готовый шаблон для копирования

Скопируйте карточку в issue, change request или описание тестового PR и заполните угловые скобки. Она одновременно служит планом работы и журналом проверки.

Локальный review перед commit
Решение: <solution>
Ветка: <branch>
Изменённые файлы: <список>
Секреты/бинарные файлы исключены: да
Команда: Git Changes → Review changes with Copilot
Комментариев: <число или none>
Принятые исправления: <список>
Отклонённые замечания и причина: <список>
Тесты после исправлений: <команды и результат>
Дата проверки продукта: 13.09.2026
Ссылка на официальную документацию: https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-code-review

Если команда использует внутреннего ассистента для подготовки change request, можно дать ему следующий промпт. Он не просит модель менять настройки и поэтому оставляет действие администратору:

Подготовь план изменения GitHub Copilot Code Review по карточке ниже.
Не придумывай текущие значения, права, тарифы или результат проверки.
Раздели ответ на: предпосылки, точный путь в интерфейсе, позитивный тест,
негативный тест, наблюдаемые критерии успеха, риски и откат.
Если в карточке нет факта, пометь его как «нужно проверить».

<вставьте заполненную карточку>

Реалистичный пример входа и результата

Вход. В ветке feature/cache изменены CacheService.cs и CacheServiceTests.cs. До commit разработчик открывает Git Changes и запускает Review changes with Copilot.

Ожидаемый результат. Visual Studio показывает ссылку на комментарии либо точное сообщение об их отсутствии. После разбора разработчик запускает тесты, очищает review comments и только затем формирует commit.

Результат считается подтверждённым только по интерфейсу GitHub и, где применимо, по timeline, merge box, атрибуциям или session log. Фраза модели, предположение администратора или отсутствие комментариев не являются достаточным доказательством. Сохраните URL тестового PR и краткую запись того, что наблюдалось до и после изменения.

Как провести позитивный и негативный тест

Позитивный тест должен попадать точно в разрешённую область: выбранный репозиторий, целевая ветка, подходящие пути и завершённые обязательные checks. До запуска запишите ожидаемое событие — например, автоматическое назначение Copilot, появление approval, видимый комментарий или MCP tool call.

Негативный тест меняет ровно одно условие. Это может быть исключённый репозиторий, файл вне glob, отсутствующий внешний идентификатор или выключенный переключатель. Если одновременно изменить несколько условий, невозможно понять причину результата. Для обоих тестов используйте безопасные изменения, которые можно закрыть без merge.