PhpStorm 2026.3: ревью PR в отдельном worktree

JetBrains выпустила PhpStorm 2026.3: в релизе — поддержка PHP 8.6 (GA которого запланирован на 19 ноября), обновлённый агентный воркспейс и новый способ ревью пул-реквестов через отдельный Git worktree. Независимое издание Laravel News подтверждает те же изменения и отдельно отмечает, что worktree-ревью решает конкретную болевую точку разработчиков на PHP-проектах — необходимость откладывать текущую работу ради просмотра чужого PR.

Что вышло

Кроме синтаксической поддержки PHP 8.6 (partial function application, clamp(), класс Duration — подробный разбор языковых изменений был в предыдущем материале), в 2026.3 обновили агентный воркспейс IDE: больше контекста о проекте передаётся встроенному AI-ассистенту при автодополнении и рефакторинге, а в интерфейс добавили более компактный обзор ревью с починкой биллинга и надёжности автоматических проверок.

Ревью в отдельном worktree

Главная практическая правка — возможность открыть GitHub pull request или GitLab merge request в отдельном Git worktree прямо из IDE, с полноценной поддержкой: подсветка типов, переход по символам, запуск тестов — всё работает на ветке PR, пока текущая ветка и незакоммиченные изменения разработчика остаются нетронутыми. До этого ревью чужого PR means либо коммитить/стешить свою работу и переключаться веткой, либо открывать второй клон репозитория вручную. Worktree в IDE убирает оба компромисса: второе дерево файлов создаётся и синхронизируется автоматически, а закрыть его после ревью — одна команда.

Copilot code review через API

Отдельно от PhpStorm, GitHub расширил управление Copilot code review: теперь настройки — кто получает автоматическое ревью, какие правила применяются, как считается биллинг — можно задавать через REST и GraphQL API на уровне всей организации и каскадом спускать до отдельных репозиториев, а не настраивать каждый репозиторий вручную через интерфейс. Для команд, которые ведут несколько проектов параллельно (разные клиентские репозитории, разные ветки релизов), это закрывает конкретный пробел: раньше включение и донастройка ИИ-ревью на 10–20 репозиториях требовало ручного прохода по каждому, теперь — один вызов API с нужной политикой.

Что это значит для команды

• Ревью PR в отдельном worktree снимает затраты на переключение контекста — особенно заметно в командах, где один разработчик держит несколько активных веток одновременно
• API-управление Copilot review полезно там, где репозиториев больше одного-двух: единая политика ревью применяется сразу ко всем, без расхождений между проектами
• Поддержка PHP 8.6 в IDE до официального GA даёт время прогнать подсветку деприкаций и типовых несовместимостей на реальном коде заранее

Для компаний, которые ведут параллельно несколько проектов — например, iOS- и Android-версии одного приложения или серверную часть и мобильный клиент в разных репозиториях, — именно такая централизованная политика ревью снимает расхождения между командами: правила для PR одинаковые везде, а не зависят от того, кто и когда настраивал конкретный репозиторий вручную. Если процесс ревью на проекте пока держится на договорённостях, а не на зафиксированной политике, разумный следующий шаг — обсудить это с командой, которая берёт на себя разработку мобильного приложения и параллельных ему репозиториев под единым стандартом кода.