# Перенос проекта из Codex в Hermes на сервере > Как перенести репозиторий с Codex на сервер и продолжить работу в Hermes: сохранить изменения, восстановить зависимости, настроить секреты и проверить рабочую папку перед разработкой. Source: https://ailoot.ai/blog/ru/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/ru/codex-project-to-hermes-server/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-83fbb1390d54546502a3d06bcf620cf74a7209cbfb6a7e387eca76ca1b7924c5 Подробнее о сервисе — в [документации Ailoot](https://ailoot.ai/docs/).
Ключевые сведения Чтобы продолжить работу в Hermes над проектом, который ты создавал в Codex, перенеси репозиторий и восстанови его рабочее окружение. Отдельная функция импорта проекта из агента для этого не требуется. Проверь сохранённые файлы и зависимости, а затем открой нужный каталог в Hermes. Инструкция рассчитана на уже настроенные сервер и Hermes, а также на наличие у тебя доступа к репозиторию.
## Подготовь проект к переносу Репозиторий — это каталог проекта вместе с историей Git. Рабочая копия содержит файлы, которые ты редактируешь. Цель переноса — создать такую копию на сервере и продолжить разработку. На этом этапе делать приложение доступным посетителям не нужно. Если Hermes ещё не установлен на сервере, сначала выполни [установку Hermes Agent на VPS](https://ailoot.ai/blog/ru/hermes-agent-vps-24-7/). Для этой инструкции уже должны работать Hermes, терминал сервера и Git. Также нужен удалённый репозиторий, доступный серверу. Если репозитория пока нет, сначала создай его и отправь туда проект без секретов. Для закрытого репозитория заранее настрой чтение от имени своей учётной записи. Не добавляй токен в URL репозитория и не отправляй его агенту в сообщении. На время переноса прекрати параллельно редактировать проект. На исходном компьютере открой терминал в каталоге проекта и выполни команды: ```bash git status --short --branch git status --short --ignored ``` Первая команда сообщает текущую ветку и состояние файлов: `M` обозначает изменённый файл, а `??` — файл, который Git пока не отслеживает. Во второй команде для игнорируемых файлов используется отметка `!!`. Чистый обычный статус сам по себе не подтверждает, что все необходимые файлы находятся в Git. Зафиксируй нужные изменения отдельным коммитом и привычным способом отправь нужную ветку в свой удалённый репозиторий. До отправки проверь содержимое коммита: в него нельзя включать ключи, пароли и реальные пользовательские данные. Если не уверен, какие изменения сохранять, попроси Codex перечислить их и объяснить назначение, не удаляя файлы и не отправляя их в репозиторий. | Элемент проекта | Что проверить перед переносом | |----|----| | Исходный код и история Git | Нужные изменения сохранены и доступны в выбранной ветке удалённого репозитория | | README и инструкции для агента | Указаны запуск, проверки и ограничения; инструкции не устарели | | Файлы зависимостей | В репозитории есть описание зависимостей и используемый проектом lockfile — файл с закреплёнными версиями | | Секреты | Предусмотрен отдельный безопасный способ задать их на сервере; значения отсутствуют в Git и переписке | | База данных и загруженные файлы | Понятно, где получить разрешённые тестовые данные и как восстановить их согласно инструкции проекта | При клонировании не переносятся автоматически внешняя база данных, содержимое игнорируемого каталога и переписка с Codex. История чатов, подписки, профили и настройки самих агентов также не входят в этот способ переноса. ## Склонируй нужную ветку на сервер Сначала на исходном компьютере сохрани результат команды: ```bash git status --porcelain=v2 --branch ``` Текущий коммит указан в строке `# branch.oid`, а ветка — в строке `# branch.head`. Коммит представляет собой сохранённую версию проекта. Для обычного проекта, где коммиты уже созданы, по этим значениям можно сравнить исходную и серверную копии. Незакоммиченные изменения такая проверка не обнаружит. На сервере перейди в каталог для проектов и клонируй туда репозиторий. В примере замени `REPOSITORY_URL` адресом своего репозитория, `BRANCH_NAME` — названием сохранённой и отправленной ветки, а `my-project` — именем нового каталога: ```bash 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. Тогда в каталоге проекта запусти: ```bash npm ci ``` Согласно [документации команды npm ci](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md), она устанавливает зависимости проекта по lockfile и не изменяет `package.json` или `package-lock.json`. Если файлы не согласованы, команда завершится с ошибкой. Перед установкой существующий каталог `node_modules` удаляется. Если при создании lockfile использовались параметры, меняющие дерево зависимостей, например `--legacy-peer-deps`, передай те же параметры и команде `npm ci`. Проверь настройки и инструкции исходного проекта. Не удаляй lockfile и не обновляй все зависимости, пытаясь скрыть первую возникшую при переносе ошибку. Перед запуском команд установки и приложения изучи инструкции самого проекта. Выполняй их в отдельной рабочей копии без доступа к боевым данным, а необходимые переменные окружения задавай вне чата и Git. По возможности проверяй проект с тестовыми учётными данными, у которых ограничены права. Если нужны база данных или файлы, сначала восстанови разрешённый тестовый набор по инструкции проекта: одних исходников для этого недостаточно. После установки выполни указанные в README проверки — тесты и сборку, если они предусмотрены. Их команды различаются от проекта к проекту. Установка зависимостей сама по себе не подтверждает работоспособность приложения. ## Открой рабочую копию в Hermes В серверном терминале перейди в корень новой копии и запусти установленный агент: ```bash cd /absolute/path/to/my-project hermes ``` Вместо `/absolute/path/to/my-project` укажи полный путь к проекту. На стартовом экране Hermes проверь рабочий каталог и среду, в которой выполняются команды терминала. Инструкция предполагает, что Hermes использует локальную среду терминала на сервере. При настройке SSH или Docker агент может работать в другом окружении; сначала выясни, по какому пути проект доступен именно там. Попроси агента сообщить фактический рабочий каталог, проверив его через терминальный инструмент, а затем прочитать README и инструкции проекта. Названия каталога в сообщении недостаточно, чтобы подтвердить его расположение. Последовательность ниже взята из конкретной закреплённой версии документации и может отличаться от версии Hermes, установленной у тебя. Сверься с действующими инструкциями в своей сессии. Hermes поддерживает `AGENTS.md`, однако чтение этого файла зависит от приоритетов контекстных файлов. Согласно [официальной документации Hermes](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md), используется один тип инструкций в таком порядке: `.hermes.md`, затем `AGENTS.override.md`, `AGENTS.md`, `CLAUDE.md` и `.cursorrules`. Поэтому перед началом работы проверь, не лежат ли рядом старый `.hermes.md` или персональный `AGENTS.override.md`: наличие `AGENTS.md` само по себе не гарантирует, что агент применит именно его. В выбранных инструкциях укажи назначение проекта, команды проверок и ограничения на изменения. Не используй их для хранения полной переписки. Если нужно перенести именно настройки между агентами, это отдельная процедура; её границы описаны в [материале о миграции с Claude Code на Codex](https://ailoot.ai/blog/ru/migrate-claude-code-to-codex/). ## Поставь одну задачу и проверь результат Сначала попроси агента изучить проект, не меняя его. Например: ``` Работаем с существующим проектом в папке, которую я указал. Подтверди фактический рабочий каталог с помощью терминального инструмента. Прочитай README и актуальные инструкции проекта. Не открывай файлы с секретами и не показывай значения переменных окружения. Перечисли команды проверок и условия, необходимые для их запуска. Пока ничего не изменяй, не устанавливай и не отправляй в репозиторий. ``` Затем выбери и согласуй небольшую задачу — например, исправление текста в интерфейсе. Укажи, какие файлы или область можно менять, и запрети попутное обновление зависимостей. Чтобы проводить эксперимент отдельно от основной копии, сначала ознакомься с [созданием отдельной рабочей копии Git worktree](https://ailoot.ai/blog/ru/codex-worktree-separate-task/). Оцени результат по изменениям в файлах и повторно выполненным проверкам проекта. Заранее сохрани исходную копию и точку возврата на случай неудачного эксперимента. Не проси агента сразу сбрасывать все изменения. Если проверка завершается ошибкой, сравни её результат с исходной копией: так можно понять, возникла ли проблема при переносе или существовала раньше. Перенос завершён, когда нужная версия исходников доступна, окружение восстановлено, необходимые данные имеются в безопасной тестовой среде, проверки проходят, а Hermes работает именно в этом каталоге. Публикация приложения для посетителей — отдельный следующий этап, который эта проверка не охватывает. Подробнее об [Ailoot](https://ailoot.ai/). ## Вопросы и ответы ### Переносит ли клонирование репозитория всю рабочую среду? Нет. Git не переносит игнорируемые файлы, внешние базы, загруженные данные, секреты и историю бесед агента. Нужные зависимости и разрешённые тестовые данные восстановите отдельно по инструкциям проекта. ### Что сравнить перед изменением серверной копии? Сравните сохранённые ветку и идентификатор коммита с исходной копией, изучите незакоммиченные изменения и попросите Hermes проверить физическую рабочую папку. Затем выполните существующие проверки проекта именно в этой копии. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.