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

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

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

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

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

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

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

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

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

Заголовок и описание 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](/docs/integrations/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 вы открываете в веб-интерфейсе хостинга.

## Похожие темы

- [Инструмент: Git](/docs/agent/tools/git)
- [GitHub MCP](/docs/mcp/github)
- [MCP-серверы](/docs/mcp)
- [Интеграция с GitHub в Создателе](/docs/integrations/github)