Перенос проекта из Codex в Hermes на сервере

Подробнее о сервисе — в документации Ailoot.

Подготовь проект к переносу#

Репозиторий — это каталог проекта вместе с историей Git. Рабочая копия содержит файлы, которые ты редактируешь. Цель переноса — создать такую копию на сервере и продолжить разработку. На этом этапе делать приложение доступным посетителям не нужно.

Если Hermes ещё не установлен на сервере, сначала выполни установку Hermes Agent на VPS. Для этой инструкции уже должны работать Hermes, терминал сервера и Git. Также нужен удалённый репозиторий, доступный серверу. Если репозитория пока нет, сначала создай его и отправь туда проект без секретов. Для закрытого репозитория заранее настрой чтение от имени своей учётной записи. Не добавляй токен в URL репозитория и не отправляй его агенту в сообщении.

На время переноса прекрати параллельно редактировать проект. На исходном компьютере открой терминал в каталоге проекта и выполни команды:

git status --short --branch
git status --short --ignored

Первая команда сообщает текущую ветку и состояние файлов: M обозначает изменённый файл, а ?? — файл, который Git пока не отслеживает. Во второй команде для игнорируемых файлов используется отметка !!. Чистый обычный статус сам по себе не подтверждает, что все необходимые файлы находятся в Git.

Зафиксируй нужные изменения отдельным коммитом и привычным способом отправь нужную ветку в свой удалённый репозиторий. До отправки проверь содержимое коммита: в него нельзя включать ключи, пароли и реальные пользовательские данные. Если не уверен, какие изменения сохранять, попроси Codex перечислить их и объяснить назначение, не удаляя файлы и не отправляя их в репозиторий.

При клонировании не переносятся автоматически внешняя база данных, содержимое игнорируемого каталога и переписка с 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 — вложенные репозитории, — нужно получить и их содержимое. Для этого предусмотрен параметр --recurse-submodules команды git clone. Применяй его, если проект действительно включает подмодули и их адреса проверены. Для других внешних ресурсов следуй дополнительным инструкциям из 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 работает именно в этом каталоге. Публикация приложения для посетителей — отдельный следующий этап, который эта проверка не охватывает.

Подробнее об Ailoot.