WorkAI
Скачать

Pull request и merge request

Как агент WorkAI открывает pull request на GitHub и merge request на GitLab после пуша: что подключить, какие ветки берутся, что будет при повторном вызове.

После того как агент запушил ветку, он умеет открыть по ней pull request на GitHub или merge request на GitLab — не выходя из чата и не переключаясь в браузер. Это продолжение git-инструментов агента: ветка, коммит и пуш делаются локально вашим системным git, а последний шаг — создание PR или MR — идёт уже через API хостинга.

Ключевое отличие от всего остального в git-инструментах: локальный git обходится тем, что уже настроено у вас в системе, а API GitHub и GitLab требуют токена. Поэтому открытие PR и MR работает не «из коробки», а после того, как вы один раз дадите доступ: для GitHub — входом через GitHub или токеном во встроенном коннекторе, для GitLab — своим MCP-сервером с токеном.

Что нужно подключить

Для GitHub — встроенный коннектор github. Устанавливать ничего не нужно: подключите его в каталоге и нажмите «Войти через GitHub» либо вставьте личный токен доступа. При входе через GitHub приложение WorkAI Agent должно быть установлено на репозиторий, в который открывается PR. Подробно — GitHub.

Для GitLab — MCP-сервер GitLab, который вы добавляете сами своей записью в mcp.json (Command Palette → «MCP: Add Server...»), с GitLab Personal Access Token. Встроенной записи для GitLab нет, поэтому в списке серверов её искать не нужно — механика добавления своего сервера описана в разделе MCP.

Вход и токены агента в обоих случаях живут на вашей машине. Серверы WorkAI их не хранят и в создании PR не участвуют: запрос уходит в GitHub или GitLab напрямую с вашего компьютера, и в истории репозитория автором PR будете вы, а не сервис.

Как это выглядит в работе

Отдельной команды для этого нет — агент вызывает инструмент сам, по ходу диалога, как и остальные свои инструменты. Достаточно сказать «запушь и открой PR» или просто «оформи это как pull request»: агент закоммитит, запушит ветку и следом откроет PR.

Перед созданием WorkAI показывает подтверждение — с указанием репозитория и того, из какой ветки в какую пойдёт PR. Для GitHub в чате дополнительно появляется вопрос с заголовком, описанием и ревьюерами будущего PR и вариантами «Создать» и «Не создавать»: пока вы не ответили, pull request не создан, и агент ждёт вас, а не вызывает инструмент повторно. Этот вопрос появляется даже тогда, когда остальные подтверждения отключены режимом автоматического одобрения (см. Режимы и разрешения).

Заголовок и описание PR агент формулирует сам по содержимому изменений; вы можете задать их текстом в запросе. Если заголовок не указан вовсе, берётся имя ветки.

Кнопка «Открыть pull request» после пуша

После того как агент успешно отправляет ветку в репозиторий на github.com, под его ответом в чате появляется кнопка «Открыть pull request». Она появляется только для github.com — не для GitLab и других хостингов — и только когда PR действительно есть из чего открыть. Кнопки не будет, если ветку отправили в основную ветку репозитория, если в ветке нет коммитов сверх основной, если отправлять было нечего, если WorkAI не смог надёжно определить основную ветку и если кнопку уже показывали для этой же ветки в текущей сессии.

Кнопка не создаёт pull request сама: клик отправляет агенту обычный текстовый запрос — такой же ход, как любое ваше сообщение, он списывает WorkCoins, и агент дальше делает то же самое, что и по словам «оформи это как pull request», включая подтверждения, описанные выше. Это не «pull request в один клик», а быстрый способ попросить о нём, не печатая текст. После клика кнопка гаснет — ответ агента уже ниже в чате. Это состояние живёт до перезапуска окна: после него кнопка снова станет активной, но второго pull request'а по той же ветке агент не создаст (см. «Повторный вызов на той же ветке» ниже).

Если агенту недоступны инструменты GitHub для pull request'ов — коннектор github не подключён, не запущен или в нём нет ни входа, ни токена, — вместо кнопки «Открыть pull request» показывается «Подключить GitHub, чтобы открывать pull request». Она хода не тратит и не отправляет агенту ничего — клик открывает хаб «Возможности агента» на разделе «Коннекторы (MCP)», где можно войти через GitHub или добавить токен. Эта подсказка показывается один раз за сессию. Если вы сами выключили инструменты GitHub для этого хода, не будет ни кнопки, ни подсказки.

Кнопку можно выключить в настройках: Настройки → WorkAI: Git → «Показывать в чате кнопку "Открыть pull request" после того, как агент отправил ветку в GitHub» (id настройки — workai.git.openPullRequestButton.enabled, по умолчанию включена).

Какие ветки и какой репозиторий берутся

Ветка-источник (head у PR, source_branch у MR) по умолчанию — текущая ветка репозитория. В состоянии detached HEAD текущей ветки нет, и агент попросит назвать её явно.

Ветка-приёмник (base / target_branch) по умолчанию — ветка по умолчанию репозитория: сначала берётся то, на что указывает HEAD удалённого репозитория, затем, если такого указателя локально нет, — main, затем master. Когда не подходит ни один вариант, инструмент честно останавливается и просит указать целевую ветку, а не угадывает её.

Репозиторий определяется по адресам remote'ов. Инструмент смотрит туда же, куда смотрит сам git при пуше: сначала branch.<ветка>.pushRemote, затем remote.pushDefault, затем branch.<ветка>.remote — включая глобальный ~/.gitconfig, а не только настройки конкретного репозитория. Благодаря этому работает и форк-схема: ветка запушена в ваш форк, а pull request открывается в апстрим-репозиторий с квалифицированным head вида владелец:ветка.

Если у репозитория несколько GitHub-remote'ов, инструмент не разрешает неоднозначность молча — он возвращает в ответе, в какой именно репозиторий ушёл PR и какие ещё варианты были, и агент обязан назвать это вам. У GitLab merge request всегда создаётся в том проекте, куда ушла ветка: кросс-проектный MR из форка в апстрим не поддержан.

Повторный вызов на той же ветке

Инструмент идемпотентен по ветке. Перед созданием он запрашивает у хостинга список открытых PR или MR и ищет среди них тот, что идёт из этой же ветки. Если такой есть — второй не создаётся: агент отвечает, что pull request по этой ветке уже открыт, и даёт на него ссылку. Так же ведёт себя повторный запрос в новом чате и после перезапуска редактора — состояние берётся из самого GitHub или GitLab, а не из памяти WorkAI.

Тот же механизм закрывает и гонку: если второй PR пытаются создать в этот же момент из другого места, GitHub и GitLab отклоняют его сами, и агент показывает это как «уже открыт», а не как ошибку.

Отдельный случай — когда проверку на уже открытый PR выполнить не удалось (например, хостинг вернул список в формате, который инструмент не разбирает). Тогда PR всё равно создаётся, но в ответе явно помечается, что проверка не отработала и это может быть второй pull request по той же ветке — агент сообщает об этом вместе с результатом. Молчаливого дубля не будет.

Неуспех всегда виден как неуспех

Инструмент считает операцию успешной, только если хостинг вернул опознаваемый pull request или merge request — с номером либо ссылкой. Любой другой ответ — ошибка авторизации, отказ API, пустой или непонятный результат — доходит до вас именно как неудача, с текстом причины. Агент не сообщает о созданном PR, если PR не создан.

Частые причины отказа названы отдельно, чтобы не разбираться в сыром ответе API:

  • коннектор не подключён или не запущен — инструмент прямо говорит, что нужно подключить встроенный коннектор github (войти через GitHub или указать токен), а для GitLab — добавить сервер в mcp.json;
  • вход истёк, токен недействителен или ему не хватает прав — ответ 401 или 403 разбирается как ошибка авторизации с подсказкой войти заново или проверить токен;
  • при входе через GitHub отказ доступа к репозиторию обычно значит, что приложение WorkAI Agent на него не установлено, — агент так и скажет и даст ссылку на установку.

Чем это отличается от GitHub в Создателе

Разные модели авторизации, и это главный источник путаницы.

Здесь, в агенте, всё происходит на вашей машине и от вашего имени: ваш локальный клон, ваш системный git, ваш вход в GitHub или личный токен. Серверы WorkAI в операции не участвуют и токен не хранят.

В интеграции с GitHub для режима Создателя — наоборот: с GitHub работает наш сервер от имени приложения workai-agent, по правам, которые вы выдали при установке приложения. Вы ставите приложение один раз и ничего у себя не запускаете, а выгрузка проекта идёт из облака, а не из вашей рабочей копии.

Что не поддерживается

  • GitHub Enterprise Server. Инструмент распознаёт только адреса на github.com, и встроенный коннектор работает только с облачным GitHub.
  • Self-hosted GitLab. Распознаются только адреса на gitlab.com: сопоставить произвольный адрес вашего сервера с тем, на какой GitLab настроен MCP-сервер, инструмент не может.
  • Кросс-проектный merge request — из форка в апстрим на GitLab. У pull request на GitHub форк-схема поддержана, у merge request — нет.

Во всех этих случаях остаётся обычный путь: агент коммитит и пушит ветку, а pull request вы открываете в веб-интерфейсе хостинга.

Похожие темы