Разборы работы с агентами можно читать в каналах.
Что подготовить до переноса
Репозиторий - папка проекта с историей изменений Git. Рабочая копия содержит файлы, которые ты редактируешь. Задача здесь - получить такую копию на сервере и продолжить разработку. Делать приложение доступным посетителям пока не требуется.
Если агента на сервере ещё нет, начни с установки Hermes Agent на VPS. Здесь понадобятся уже работающий Hermes, терминал сервера и Git. Нужен удалённый репозиторий, доступный с сервера; если его ещё нет, сначала создай его и сохрани туда проект без секретов. Для закрытого репозитория заранее настрой доступ на чтение от своей учётной записи; не вставляй токен в адрес репозитория или сообщение агенту.
Останови параллельные правки проекта на время переноса. На исходном компьютере открой терминал именно в папке проекта и выполни:
git status --short --branch
git status --short --ignoredПервая команда показывает ветку и состояние файлов. M означает изменение, ?? - файл, который Git ещё не отслеживает. Во второй команде игнорируемые файлы помечаются !!. Обычный чистый статус не доказывает, что у тебя нет нужных файлов вне Git.
Сохрани нужные изменения отдельным коммитом и отправь нужную ветку в свой удалённый репозиторий привычным способом. Перед отправкой проверь состав коммита: ключи, пароли и реальные пользовательские данные туда попадать не должны. Если не знаешь, какие изменения сохранять, сначала попроси Codex показать их список и объяснить назначение, без удаления файлов и отправки в репозиторий.
| Часть проекта | Что проверить перед переносом |
|---|---|
| Исходники и история Git | Нужные изменения сохранены и доступны в выбранной ветке удалённого репозитория |
| README и инструкции агенту | Описаны запуск, проверки и ограничения; инструкции актуальны |
| Файлы зависимостей | Сохранены описание зависимостей и используемый проектом lockfile, то есть файл закреплённых версий |
| Секреты | Есть отдельный безопасный способ задать их на сервере; значения не лежат в Git и не пересылаются в чат |
| База данных и загруженные файлы | Понятно, откуда взять разрешённые тестовые данные и как восстановить их по инструкции проекта |
Не рассчитывай, что клонирование репозитория перенесёт внешнюю базу, содержимое игнорируемой папки или переписку с Codex. История чатов, подписки, профили и настройки самих агентов в этот способ переноса не входят.
Для дальнейшей работы с ИИ-агентами можно посмотреть актуальную программу практикума.
Скопируй нужную ветку на сервер
Сначала на исходном компьютере сохрани вывод:
git status --porcelain=v2 --branchВ строке # branch.oid указан текущий коммит, в # branch.head - ветка. Коммит - сохранённая версия проекта. Для обычного проекта с уже созданными коммитами это позволяет сравнить исходную и новую копии; незакоммиченные изменения таким сравнением не проверяются.
На сервере перейди в каталог, где будешь хранить проекты. Клонируй свой репозиторий в новую папку. В шаблоне ниже замени REPOSITORY_URL адресом своего репозитория, BRANCH_NAME именем сохранённой и отправленной ветки, а my-project желаемым именем новой папки:
git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branchЭто шаблон, а не готовый адрес для копирования. git clone создаёт папку и рабочую копию выбранной ветки. Существующая папка назначения должна быть пустой: не удаляй её содержимое ради повторного запуска, выбери новое имя.
Сравни # branch.oid в обеих копиях. Если значения различаются, не начинай исправлять код на сервере: проверь выбранную ветку, отправленные коммиты и отсутствие параллельных изменений. Если в выводе статуса есть изменённые файлы, разберись с ними отдельно. Не используй очистку или принудительный сброс как способ «добиться совпадения».
В репозиториях с Git submodules, то есть вложенными репозиториями, потребуется также получить их содержимое. Для этого у git clone есть параметр --recurse-submodules; используй его, если проект действительно содержит подмодули и их адреса проверены. Проектам с другими внешними ресурсами может требоваться дополнительная процедура из README.
Восстанови зависимости по правилам проекта
Сначала прочитай README и файлы настройки проекта. Выясни, какая версия среды выполнения нужна и каким менеджером устанавливаются зависимости. Не заменяй привычный инструмент проекта на npm только потому, что он есть в примере ниже.
Условный пример для Node.js и npm: в репозитории есть согласованные package.json и package-lock.json, а на сервере установлена подходящая проекту версия Node.js. Тогда в папке проекта выполни:
npm ciПо документации npm ci, команда устанавливает зависимости целого проекта по lockfile, не переписывая package.json и package-lock.json. Если их содержимое не согласовано, установка завершится ошибкой. Имеющаяся папка node_modules перед установкой удаляется.
Если lockfile был создан с параметрами, влияющими на дерево зависимостей, например --legacy-peer-deps, для npm ci нужны те же параметры. Проверь инструкции и настройки исходного проекта. Не удаляй lockfile и не обновляй все зависимости, чтобы скрыть первую ошибку переноса.
Перед установкой проверь команды установки и запуска в собственном проекте. Выполняй их в отдельной рабочей копии без доступа к боевым данным, а необходимые значения окружения задавай вне чата и Git. Для проверки проекта по возможности используй тестовые учётные данные с ограниченными правами. Если проект зависит от базы или файлов, сначала восстанови разрешённый тестовый набор по его инструкции; одинаковые исходники не заменяют эти данные.
После установки выполни существующие проверки из README: тесты и сборку, если они предусмотрены. Названия команд зависят от проекта. Успешная установка зависимостей ещё не означает, что приложение работает.
Открой рабочую копию в Hermes
В терминале сервера перейди в корень новой копии и запусти уже установленный агент:
cd /absolute/path/to/my-project
hermesЗдесь /absolute/path/to/my-project - место для полного пути к твоему проекту. На стартовом экране Hermes проверь рабочий каталог и среду выполнения терминальных команд. Этот способ запуска рассчитан на локальную среду терминала Hermes на сервере. Если настроены SSH или Docker, агент может выполнять команды в другой среде; сначала уточни доступный там путь к проекту.
Попроси агента подтвердить фактическую рабочую папку его инструментом терминала, затем прочитать README и инструкции проекта. Не считай название папки в сообщении достаточной проверкой.
Порядок ниже указан в закреплённой версии документации и может отличаться в твоей установленной версии Hermes. Проверь действующие инструкции в своей сессии. Hermes поддерживает AGENTS.md, но его чтение зависит от приоритетов файлов контекста. По официальной документации Hermes выбирается один тип инструкций: .hermes.md, затем AGENTS.override.md, AGENTS.md, CLAUDE.md и .cursorrules. Поэтому наличие старого .hermes.md или личного AGENTS.override.md нужно проверить до работы: не рассчитывай, что агент обязательно применит лежащий рядом AGENTS.md.
В выбранных инструкциях сохрани назначение проекта, команды проверок и ограничения на изменения. Не превращай их в архив переписки. Если нужно передавать именно настройки между агентами, это другой процесс; его границы разобраны в материале о миграции с Claude Code на Codex.
Дай одну задачу и проверь результат
Начни с чтения проекта, без правок. Например:
Работаем с существующим проектом в указанной мной папке.
Подтверди фактический рабочий каталог инструментом терминала.
Прочитай README и действующие инструкции проекта.
Не открывай файлы с секретами и не выводи значения окружения.
Назови команды проверок и необходимые условия их запуска.
Пока ничего не меняй, не устанавливай и не отправляй в репозиторий.После этого согласуй одну небольшую задачу, например исправление текста в интерфейсе. Укажи файлы или область изменений и запрети попутное обновление зависимостей. Если хочешь отделить эксперимент от основной копии, сначала разберись с отдельной рабочей копией Git worktree.
Принимай результат по изменениям файлов и повторным проверкам проекта. На случай неудачного эксперимента заранее сохрани исходную копию и точку возврата; не проси агента массово сбросить все изменения. Если проверка не проходит, сравни ошибку с исходной копией: это помогает отделить проблему переноса от дефекта, который был раньше.
Перенос можно считать завершённым, когда нужная версия исходников на месте, окружение восстановлено, необходимые данные доступны в безопасной тестовой среде, проверки проходят, а Hermes работает именно в этой папке. Публикация приложения для посетителей - следующий самостоятельный этап, в эту проверку она не входит.
Для дальнейшей работы с агентами можно свериться с актуальной программой практикума ниже.
Новые материалы - дайджестом, без спама
Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.
