DeepSeek Harness
Меню глав

← К оглавлению

[позже] GitHub OAuth-плагины с нуля

Глава 4. Подключение к GitHub — доступ с меньшим риском

В прошлой главе вы успешно запустили агента и дали ему простую задачу в тестовой папке. Теперь настало время подключить его к GitHub — чтобы он мог не просто читать файлы на вашем компьютере, но и самостоятельно коммитить, пушить, создавать Pull Request'ы и управлять репозиториями.

Но есть один нюанс: вы даёте агенту доступ к вашему коду и, возможно, к закрытым репозиториям. Поэтому безопасность — главная тема этой главы.


4.1. Зачем агенту доступ к GitHub

Если коротко: чтобы вы перестали быть «курьером» между агентом и GitHub.

В Cursor вы получали код, потом сами открывали терминал, писали git add, git commit, git push, шли на сайт GitHub, создавали Pull Request. В DSH агент может делать всё это сам.

Что агент сможет делать после подключения:

Действие Как это было в Cursor Как будет в DSH
Написать код ✅ ИИ писал ✅ ИИ пишет
Закоммитить изменения ❌ вы сами ✅ агент сам
Запушить на GitHub ❌ вы сами ✅ агент сам
Создать Pull Request ❌ вы сами идёте на сайт ✅ агент сам создаёт PR
Прочитать существующий PR ❌ вы сами открываете ✅ агент читает и комментирует
Создать Issue ❌ вы сами ✅ агент создаёт
Найти код в репозитории ❌ вы сами ищете ✅ агент ищет через GitHub API

Простыми словами: вы даёте агенту задачу, а он сам управляет всем циклом работы с GitHub — от написания кода до создания Pull Request'а.


4.2. Два способа подключения — и какой выбрать для маркетолога

Есть два основных способа дать агенту доступ к GitHub. Они различаются по сложности и уровню безопасности.

Способ 1: OAuth Device Flow (рекомендуемый для вас)

Этот способ похож на вход в приложение через «Войти с Google» — вы нажимаете кнопку, GitHub просит подтверждение в браузере, вы соглашаетесь — и всё готово.

Плюсы:
- Не нужно копировать и вставлять токены — всё делается через браузер.
- Токен сохраняется только на вашем компьютере — не попадает в конфиги и логи.
- Можно отозвать доступ в любой момент через настройки GitHub.
- Подходит для веб-интерфейса (Web UI).

Минусы:
- Требует, чтобы вы открыли браузер и подтвердили вход.
- Не подходит для полностью автоматических (headless) запусков на сервере.

Способ 2: Personal Access Token (PAT)

Это когда вы создаёте специальный ключ в настройках GitHub, копируете его и вставляете в DSH.

Плюсы:
- Подходит для headless-режима (сервер, автоматические задачи).
- Можно настроить минимальные права — только на один репозиторий, только на чтение и т.д.

Минусы:
- Нужно разбираться, как создавать токен в GitHub.
- Если токен скомпрометирован — злоумышленник получит доступ.

Для маркетолога я настоятельно рекомендую Способ 1 (OAuth) — он проще и безопаснее, потому что вы не работаете с ключами вручную.


4.3. Пошаговая инструкция: подключение через OAuth (самый простой способ)

Мы будем использовать связку плагинов вокруг dsh-github и кнопки входа dsh-github-connect — она добавляет в интерфейс «Подключить GitHub» (OAuth Device Flow) и даёт агенту tools для API.

Единые имена в учебнике (не путайте с устаревшим ярлыком «github-connector»):

Пакет Роль
dsh-github Ядро интеграции
dsh-github-rest GitHub REST API
dsh-tool-github Tools для агента (PR, Issue и т.д.)
dsh-github-connect Кнопка OAuth / подключение в UI
dsh-ui-github Элементы Web UI (опционально для headless)

Шаг 1. Убедитесь, что у вас есть всё необходимое

Перед установкой плагина проверьте:
- Node.js ^22.19.0 или >=24 (не 23.x; проверьте node -v).
- Установлен pnpm — менеджер пакетов. Если нет, установите командой:
bash npm install -g pnpm
- DSH уже запускался хотя бы раз (вы делали это в Главе 3).

Шаг 2. Установите плагин

Откройте терминал и выполните команду:

dsh plugin --profile web add dsh-github dsh-github-rest dsh-tool-github dsh-github-connect dsh-ui-github

Что означают эти названия:
- dsh-github — основная логика плагина.
- dsh-github-rest — работа с GitHub REST API.
- dsh-tool-github — инструменты для агента (чтение PR, создание Issue и т.д.).
- dsh-github-connect — кнопка подключения в интерфейсе.
- dsh-ui-github — элементы интерфейса (PR-статус, кнопки).

Если вы используете не web, а другой профиль (например, desktop), замените web на название вашего профиля. dsh-ui-github нужен только для веб-интерфейса — если вы работаете в headless-режиме, его можно не ставить.

Шаг 3. Перезапустите DSH

Закройте терминал с DSH (нажмите Ctrl+C) и запустите заново:

dsh web

Шаг 4. Подключите GitHub в интерфейсе

  1. Откройте веб-интерфейс DSH (http://127.0.0.1:3080).
  2. Зайдите в Настройки (Settings) → Плагины (Plugins).
  3. Найдите раздел плагина GitHub.
  4. Нажмите кнопку «Подключить GitHub» (или «Connect GitHub»).
  5. Откроется окно GitHub — войдите в свой аккаунт и подтвердите доступ.
  6. Всё! Токен сохранится на вашем компьютере и не попадёт в конфигурационные файлы.

Шаг 5. Проверьте, что всё работает

В диалоге с агентом напишите:

«Покажи список моих репозиториев на GitHub»

Если агент ответил списком — подключение работает. Если нет — проверьте, что вы авторизовались, и попробуйте перезапустить DSH.


4.4. Альтернативный способ: через Personal Access Token (для headless-режима)

Если вы планируете запускать агента на сервере без браузера (например, по расписанию), OAuth не подойдёт — нужен токен.

Шаг 1. Создайте токен в GitHub

  1. Зайдите на GitHub → Settings (иконка шестерёнки в правом верхнем углу).
  2. В левом меню выберите Developer settingsPersonal access tokensTokens (classic).
  3. Нажмите Generate new token (classic).
  4. Дайте токену имя (например, dsh-agent).
  5. Выберите срок действия (рекомендую 30–90 дней, не вечный).
  6. Выберите минимальные права (scopes):
    - repo — доступ к репозиториям (если нужно читать и писать код).
    - workflow — если агент должен управлять GitHub Actions.
    - user — если агенту нужно читать информацию о пользователе.

Важно: не давайте прав больше, чем нужно. Если агент только читает код — достаточно repo с галочкой «read-only».

  1. Нажмите Generate token и скопируйте токен сразу — после закрытия страницы вы его больше не увидите.

Шаг 2. Передайте токен в DSH

Есть два способа:

Способ 2а — через переменную окружения (рекомендуется):

export GITHUB_TOKEN="ваш_токен"

Или на Windows:

setx GITHUB_TOKEN "ваш_токен"

После этого перезапустите DSH — он подхватит токен автоматически.

Способ 2б — через настройки DSH:
1. В веб-интерфейсе откройте Settings → Credentials.
2. Добавьте новую переменную с именем GITHUB_TOKEN и вставьте токен.

Шаг 3. Проверьте

В диалоге с агентом напишите:

«Покажи список моих репозиториев»

Если ответ есть — всё работает.


4.5. Как защитить себя: правила безопасности для маркетолога

Это самый важный раздел главы. Вы даёте агенту доступ к вашему коду — и если что-то пойдёт не так, последствия могут быть неприятными.

Правило 1: Используйте тестовый репозиторий

Первые несколько запусков делайте только в тестовом репозитории, который не жалко сломать. Создайте отдельный репозиторий с названием dsh-test и работайте только в нём, пока не поймёте, как агент behaves.

Правило 2: Ограничьте права токена

Если используете PAT (Personal Access Token), давайте минимально возможные права:
- Только на один репозиторий (не на все).
- Только на чтение, если агент не должен ничего менять.
- Устанавливайте срок действия (не «вечный»).

В GitHub при создании токена можно выбрать «Only select repositories» и указать конкретный репозиторий.

Правило 3: Не храните токен в коде

Никогда не вставляйте токен в промпт или в файлы проекта. Используйте переменные окружения или настройки DSH (Credentials).

Правило 4: Включайте подтверждение опасных действий

Некоторые плагины (например, dsh-git-plugins) поддерживают подтверждение (approval) для опасных действий — force push, merge, удаление веток. Агент запросит ваше разрешение перед выполнением таких команд.

В плагине dsh-github опасные операции (удаление, force push, merge PR, закрытие Issue) тоже требуют подтверждения.

Правило 5: Регулярно проверяйте, какие доступы вы дали

Раз в месяц заходите в настройки GitHub → ApplicationsAuthorized OAuth Apps и отзывайте доступы, которые больше не используете.


4.6. Что делать, если подключение не работает

Проблема Что проверять
Кнопка «Подключить GitHub» не появляется Плагин установлен? Перезапустили DSH после установки?
Ошибка авторизации Правильно ли вы ввели логин/пароль в GitHub?
Агент не видит репозитории Есть ли у токена права repo?
Ошибка «rate limit» GitHub ограничивает количество запросов. Подождите час и попробуйте снова.
Токен не работает Не истёк ли срок действия?

Универсальный совет: если что-то пошло не так, выполните команду:

dsh --dump-config --profile web

Она покажет, какие плагины и настройки реально загружены — это поможет понять, где ошибка.


4.7. Продвинутый вариант: плагин с «памятью» (dsh-git-plugins)

Если вы планируете часто работать с GitHub и хотите, чтобы агент запоминал ваши привычки (как вы называете ветки, в каком стиле пишете коммиты, какие стратегии merge предпочитаете) — есть более мощный плагин dsh-git-plugins от сообщества.

Что он даёт дополнительно:
- Самообучающаяся память — агент запоминает ваши предпочтения между сессиями.
- Работа с GitLab, Bitbucket, Azure DevOps, Gitea — не только с GitHub.
- 8 инструментов: git_repo, git_inspect, git_pr, git_issues, git_release, git_security, git_ci, git_memory.

Установка:

dsh plugin --profile web add github:sakthiveltofficial/dsh-git-plugins

После установки перезапустите DSH.

Но предупреждение: этот плагин сложнее в настройке и требует указания токенов через переменные окружения. Для начала используйте связку dsh-github + dsh-github-connect — её достаточно для 90% задач.


4.8. Итоговый чек-лист

После прочтения этой главы вы должны уметь:

  • [x] Понимать, зачем агенту доступ к GitHub.
  • [x] Выбирать между OAuth (для веб-интерфейса) и PAT (для headless-режима).
  • [x] Устанавливать связку dsh-github + dsh-github-connect (и связанные пакеты из §4.3).
  • [x] Подключать GitHub через OAuth в один клик.
  • [x] Создавать Personal Access Token с минимальными правами.
  • [x] Передавать токен в DSH через переменную окружения.
  • [x] Понимать основные правила безопасности.
  • [x] Диагностировать типичные проблемы.

Следующая глава (Глава 5) будет посвящена подключению к вашему серверу (VPS, хостинг) — чтобы агент мог не только писать код и пушить его на GitHub, но и самостоятельно деплоить сайты на ваш сервер.


Квиз по главе 10 вопросов · нажмите, чтобы открыть

Ответьте на все вопросы и сдайте квиз — сразу будет оценка и отсылки к тексту, где доучить ошибки.

Вопрос 1 из 10

Зачем агенту доступ к GitHub?

Вопрос 2 из 10

Какой способ подключения рекомендован маркетологу как самый простой?

Вопрос 3 из 10

Когда чаще вспоминают Personal Access Token (PAT)?

Вопрос 4 из 10

Главный акцент главы 4?

Вопрос 5 из 10

Что разумнее для маркетолога на старте?

Вопрос 6 из 10

Если подключение к GitHub не работает, что делать по логике главы?

Вопрос 7 из 10

Зачем нужны правила безопасности для маркетолога в этой главе?

Вопрос 8 из 10

Что такое продвинутый вариант с «памятью» в конце главы?

Вопрос 9 из 10

Можно ли считать PAT более «опасным», если обращаться с ним неаккуратно?

Вопрос 10 из 10

Итог главы 4?