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 работает не «из коробки», а после подключения соответствующего MCP-сервера с вашим личным токеном.

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

Для GitHub — встроенный MCP-сервер github и ваш личный Personal Access Token в нём. Сервер уже есть в списке, устанавливать ничего не нужно: достаточно запустить его и ввести токен. Как это сделать — GitHub MCP.

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

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

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

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

Перед созданием WorkAI показывает подтверждение — с указанием репозитория и того, из какой ветки в какую пойдёт PR. У GitHub есть ещё и собственная форма подтверждения, которую его MCP-сервер показывает прямо в чате: до её отправки pull request не создан. Агент это понимает и в такой ситуации просто ждёт вас, а не пытается вызвать инструмент повторно. Эта форма — гейт со стороны GitHub, поэтому она появляется даже тогда, когда собственные подтверждения WorkAI отключены режимом автоматического одобрения (см. Режимы и разрешения).

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

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

Ветка-источник (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:

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

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

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

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

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

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

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

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

Похожие темы