Přesun projektu z Codexu do Hermes na serveru

Nápovědu k používání služby najdete v dokumentaci Ailoot.

Co připravit před přesunem projektu z Codexu do Hermes?#

Repozitář je složka projektu s historií změn v Gitu. Pracovní kopie obsahuje soubory, které upravujete. Cílem je dostat tuto kopii na server a pokračovat ve vývoji. Aplikaci zatím nemusíte zpřístupňovat návštěvníkům.

Pokud agent ještě není na serveru nainstalovaný, začněte návodem Instalace Hermes Agent na VPS. Budete potřebovat funkční instalaci Hermes, terminál serveru a Git. Potřebujete vzdálený repozitář, ke kterému má server přístup; pokud ho zatím nemáte, nejprve ho vytvořte a uložte do něj projekt bez tajných údajů. U soukromého repozitáře si předem nastavte přístup pro čtení ze svého účtu; nevkládejte token do URL repozitáře ani do zprávy agentovi.

Během přenosu pozastavte souběžné úpravy projektu. Na zdrojovém počítači otevřete terminál přímo ve složce projektu a spusťte:

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

První příkaz zobrazí větev a stav souborů. M označuje změnu a ?? soubor, který Git zatím nesleduje. Ve druhém příkazu jsou ignorované soubory označené !!. Běžný čistý stav nedokazuje, že mimo Git nemáte žádné potřebné soubory.

Potřebné změny uložte do samostatného commitu a obvyklým způsobem odešlete správnou větev do vzdáleného repozitáře. Než změny odešlete, zkontrolujte, co commit obsahuje: nesmí v něm být klíče, hesla ani skutečná uživatelská data. Pokud nevíte, které změny uložit, nejprve požádejte Codex, aby je vyjmenoval a vysvětlil jejich účel, aniž by mazal soubory nebo odesílal změny do repozitáře.

Nepředpokládejte, že se klonováním repozitáře přenesou externí databáze, obsah ignorované složky nebo vaše konverzace s Codexem. Historie chatu, předplatná, profily a vlastní nastavení agentů do tohoto způsobu přenosu nepatří.

Zkopírujte správnou větev na server#

Nejprve na zdrojovém počítači uložte výstup tohoto příkazu:

git status --porcelain=v2 --branch

Řádek # branch.oid zobrazuje aktuální commit a # branch.head název větve. Commit je uložená verze projektu. U běžného projektu s existujícími commity vám to umožní porovnat zdrojovou a novou kopii; toto porovnání nekontroluje necommitované změny.

Na serveru přejděte do adresáře, kam budete ukládat projekty. Naklonujte repozitář do nové složky. V níže uvedené šabloně nahraďte REPOSITORY_URL adresou URL repozitáře, BRANCH_NAME názvem větve, kterou jste uložili a odeslali, a my-project názvem nové složky:

git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch

Jde o šablonu, nikoli o připravenou URL ke zkopírování. Příkaz git clone vytvoří složku a pracovní kopii vybrané větve. Pokud cílová složka už existuje, musí být prázdná: nemažte její obsah, abyste příkaz spustili znovu; zvolte nový název.

Porovnejte # branch.oid v obou kopiích. Pokud se hodnoty liší, nezačínejte na serveru opravovat kód: zkontrolujte vybranou větev, odeslané commity a to, zda nebyly provedeny souběžné změny. Pokud výstup stavu ukazuje upravené soubory, prozkoumejte je zvlášť. Nepoužívejte úklid ani vynucený reset jako způsob, jak je „sjednotit“.

Repozitáře se submoduly Gitu, tedy vnořenými repozitáři, vyžadují také stažení jejich obsahu. git clone má pro tento účel volbu --recurse-submodules; použijte ji, pokud projekt skutečně obsahuje submoduly a jejich URL byly ověřeny. Projekty s dalšími externími zdroji mohou vyžadovat dodatečný postup popsaný v README.

Obnovte závislosti podle pravidel projektu#

Nejprve si přečtěte README a konfigurační soubory projektu. Zjistěte, jaká verze běhového prostředí je vyžadována a který správce balíčků se používá k instalaci závislostí. Nenahrazujte obvyklý nástroj projektu npm jen proto, že se objevuje v příkladu níže.

Hypotetický příklad pro Node.js a npm: repozitář obsahuje konzistentní soubory package.json a package-lock.json a na serveru je nainstalovaná verze Node.js vhodná pro projekt. V takovém případě spusťte ve složce projektu:

npm ci

Podle dokumentace npm ci tento příkaz nainstaluje závislosti celého projektu ze souboru zámku, aniž by přepsal package.json nebo package-lock.json. Pokud jejich obsah není konzistentní, instalace selže. Před instalací se smaže případná existující složka node_modules.

Pokud byl soubor zámku vytvořen s volbami, které ovlivňují strom závislostí, například --legacy-peer-deps, potřebuje npm ci stejné volby. Zkontrolujte pokyny a nastavení zdrojového projektu. Nemažte soubor zámku ani neaktualizujte všechny závislosti, abyste skryli první chybu při přenosu.

Před instalací si ve vlastním projektu ověřte příkazy instalace a spuštění. Spusťte je v samostatné pracovní kopii bez přístupu k produkčním datům a potřebné proměnné prostředí nastavte mimo chat a Git. K ověření projektu pokud možno použijte testovací přihlašovací údaje s omezenými oprávněními. Pokud projekt závisí na databázi nebo souborech, nejprve podle pokynů obnovte povolenou testovací datovou sadu; stejné zdrojové soubory tato data nenahrazují.

Po instalaci spusťte existující kontroly z README: testy a sestavení, pokud jsou k dispozici. Názvy příkazů závisí na projektu. Úspěšná instalace závislostí ještě neznamená, že aplikace funguje.

Otevřete pracovní kopii v Hermes#

V terminálu serveru přejděte do kořenové složky nové kopie a spusťte již nainstalovaného agenta:

cd /absolute/path/to/my-project
hermes

/absolute/path/to/my-project je zde zástupná hodnota pro úplnou cestu k projektu. Na úvodní obrazovce Hermes zkontrolujte pracovní adresář a prostředí, ve kterém se spouštějí příkazy terminálu. Tento způsob spuštění je určen pro místní terminálové prostředí Hermes na serveru. Pokud je nakonfigurované SSH nebo Docker, agent může spouštět příkazy v jiném prostředí; nejprve ověřte cestu k projektu, která je tam dostupná.

Požádejte agenta, aby pomocí svého terminálového nástroje potvrdil skutečnou pracovní složku, a poté si přečtěte README a pokyny projektu. Samotný název složky uvedený ve zprávě nepovažujte za dostatečné ověření.

Níže uvedené pořadí je uvedeno v připnuté verzi dokumentace a ve vaší nainstalované verzi Hermes se může lišit. Ověřte aktuální pokyny ve své relaci. Hermes podporuje AGENTS.md, ale to, zda tento soubor načte, závisí na prioritách kontextových souborů. Podle oficiální dokumentace Hermes se vybírá jeden typ souboru s pokyny: .hermes.md, potom AGENTS.override.md, AGENTS.md, CLAUDE.md a .cursorrules. Před zahájením práce zkontrolujte, zda není přítomen starý .hermes.md nebo osobní AGENTS.override.md: nepředpokládejte, že agent nutně použije soubor AGENTS.md, pokud je vedle nich.

Ve vybraných pokynech zachovejte účel projektu, příkazy ke kontrolám a omezení změn. Nedělejte z nich archiv konverzací. Pokud potřebujete přenést i samotná nastavení agentů, jde o jiný postup; jeho rozsah je vysvětlen v návodu k migraci z Claude Code do Codexu.

Zadejte agentovi jeden úkol a zkontrolujte výsledek#

Začněte tím, že si projekt přečtete, aniž byste v něm prováděli změny. Například:

Pracujeme se stávajícím projektem ve složce, kterou jsem určil.
Pomocí terminálového nástroje potvrď skutečný pracovní adresář.
Přečti README a aktuální pokyny projektu.
Neotevírej soubory s tajnými údaji ani nevypisuj hodnoty prostředí.
Vypiš příkazy ke kontrolám a předpoklady pro jejich spuštění.
Zatím nic neměň ani neinstaluj a nic neodesílej do repozitáře.

Potom se dohodněte na jednom malém úkolu, například na opravě textu v rozhraní. Určete soubory nebo oblast, které se mají změnit, a zakažte vedlejší aktualizace závislostí. Pokud chcete experiment oddělit od hlavní kopie, nejprve se seznamte s oddělenou pracovní kopií Git worktree.

Výsledek přijměte na základě změn souborů a opakovaného spuštění kontrol projektu. Před potenciálně neúspěšným experimentem uložte zdrojovou kopii a bod obnovení; nežádejte agenta, aby hromadně resetoval všechny změny. Pokud kontrola selže, porovnejte chybu se zdrojovou kopií: pomůže to rozlišit problém s přenosem od vady, která existovala už předtím.

Přenos lze považovat za dokončený, když je k dispozici požadovaná verze zdrojových souborů, prostředí je obnovené, potřebná data jsou dostupná v bezpečném testovacím prostředí, kontroly procházejí a Hermes pracuje právě v této složce. Zveřejnění aplikace pro návštěvníky je samostatná další fáze a tato kontrola ho nezahrnuje.

Poznejte Ailoot.