Как ИИ-агент подключается к GitHub и GitLab

Обновлено 20 августа 2026 г. · 6 мин чтения

Как подключить GitHub к ИИ-редактору — вопрос не про кнопку «войти», а про то, какой из двух моделей доступа использует инструмент: официальное приложение (GitHub App) с правами, которые выдаёт владелец репозитория, или личный токен пользователя (PAT), с которым инструмент действует от вашего имени. От этого выбора зависит, что агент может сделать дальше: закоммитить правку или самостоятельно открыть pull request. В WorkAI IDE агент подключается вторым способом. Дальше разбираем, что это означает на практике, и отдельно — почему для GitLab всё иначе.

Два способа, которыми ИИ-инструмент получает доступ к репозиторию

GitHub App — отдельная сущность в экосистеме GitHub. Организация или разработчик регистрирует приложение и описывает нужные права: чтение кода, запись коммитов, работа с pull request, реакция на проверки CI. Владелец репозитория один раз даёт согласие через экран установки, и дальше приложение получает токен только на те репозитории, где его установили, не на весь аккаунт. Права видны и отзываются в настройках репозитория в любой момент, независимо от самого ИИ-инструмента.

Личный токен устроен проще и грубее. Пользователь сам создаёт Personal Access Token в настройках GitHub, выбирает область действия (например, полный доступ к репозиториям) и вставляет токен в инструмент напрямую. Дальше инструмент действует буквально от имени пользователя: всё, что доступно вам, доступно и ему, пока токен не отозван вручную. Ждать установки приложения и согласия администратора организации не нужно, но и разграничить права по конкретной задаче нельзя — весь диапазон выдаётся сразу.

Что умеет агент в WorkAI IDE

В WorkAI IDE у агента 13 структурных git-инструментов. Все идут через официальный API vscode.git — тот же, которым пользуется штатное Git-расширение редактора, не через голый терминал.

Авторизация при этом целиком системная: агент работает с теми git-кредами (SSH-ключом, keychain, сохранённым логином), что уже настроены у вас в системе. WorkAI-сторона их не хранит и не видит. Без дополнительной настройки агент:

• смотрит статус репозитория и историю коммитов;
• стейджит файлы и коммитит изменения;
• пушит в существующую ветку или заводит новую;
• переключается между ветками и откатывает незакоммиченные правки.

Для действий за пределами обычного git — включая открытие pull request — в IDE есть встроенный, но не включённый по умолчанию MCP-сервер GitHub. Один раз вставляете личный токен (PAT) в подсказку при подключении — и дальше агенту доступен отдельный инструмент workai_git_open_pull_request: попросите открыть PR после пуша, и агент сам заведёт его с нужными base/head, а при повторном вызове на той же ветке не наплодит дубли — найдёт уже открытый PR и не станет создавать второй.

Отдельной кнопки «Открыть PR» в интерфейсе нет — это разговорное действие: агент вызывает инструмент, когда вы попросите словами или когда сам сочтёт логичным продолжением после пуша. Без настроенного токена агент честно скажет, что для этого действия нужно сначала подключить MCP-сервер GitHub, а не промолчит и не притворится, что всё получилось.

GitLab устроен почти так же

Структурные git-инструменты не завязаны на конкретный хостинг — это обычные операции git, и они одинаково работают что с GitHub, что с GitLab, что с любым другим remote.

Для API-уровня — тот же принцип, тот же PAT-подход, только сервер и инструмент другие: встроенный MCP-сервер GitLab (пакет @zereight/mcp-gitlab, токен со scope api) даёт агенту инструмент workai_git_open_merge_request — по смыслу и поведению зеркало GitHub-версии, включая проверку на уже открытый MR перед созданием.

Одно реальное отличие: у GitLab-инструмента пока не решена задача self-hosted-инсталляций — сопоставление владельца и репозитория из remote-адреса надёжно работает только для gitlab.com, для собственного корпоративного сервера потребуется доработка. Для GitHub-версии такого ограничения нет.

Частые вопросы