# Přesun projektu z Codexu do Hermes na serveru > Přenos repozitáře na server pro práci v Hermes: uložené změny, závislosti, tajné údaje, pracovní složka a kontroly před pokračováním vývoje. Source: https://ailoot.ai/blog/cs/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/cs/codex-project-to-hermes-server/ Language: cs Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-06f8fa7db9650a34896e44e07b4aafb2e5bd6c81ed028bd779dbe87c65f2b499 Nápovědu k používání služby najdete v [dokumentaci Ailoot](https://ailoot.ai/docs/).
Hlavní poznatek Chcete-li pokračovat v práci v Hermes s projektem vytvořeným pomocí Codexu, přeneste samotný repozitář a obnovte jeho prostředí. Pro tento postup nepotřebujete samostatný krok „importovat projekt od agenta“. Nejprve zkontrolujte uložené soubory a závislosti, potom v Hermes otevřete správnou složku. Tento návod předpokládá, že server i Hermes už máte nastavené a že máte přístup k repozitáři.
## 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](https://ailoot.ai/blog/cs/hermes-agent-vps-24-7/). 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: ```bash 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. | Část projektu | Co zkontrolovat před přenosem | |----|----| | Zdrojové soubory a historie Gitu | Potřebné změny jsou uložené a dostupné ve vybrané větvi vzdáleného repozitáře | | README a pokyny pro agenty | Jsou zdokumentované kroky spuštění, kontroly a omezení; pokyny jsou aktuální | | Soubory se závislostmi | Jsou uložené definice závislostí a používaný soubor zámku projektu, který připíná verze | | Tajné údaje | Existuje samostatný bezpečný způsob, jak je nastavit na serveru; jejich hodnoty nejsou v Gitu ani posílané v chatu | | Databáze a nahrané soubory | Víte, kde získat povolená testovací data a jak je obnovit podle pokynů projektu | 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: ```bash 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: ```bash 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: ```bash npm ci ``` Podle [dokumentace npm ci](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md) 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: ```bash 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](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md) 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](https://ailoot.ai/blog/cs/migrate-claude-code-to-codex/). ## 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](https://ailoot.ai/blog/cs/codex-worktree-separate-task/). 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](https://ailoot.ai/). ## Časté otázky ### Přenese klonování repozitáře celé pracovní prostředí? Ne. Git nepřenese ignorované soubory, externí databáze, nahraná data, tajné údaje ani historii chatu agenta. Potřebné závislosti a povolená testovací data obnovte zvlášť podle projektových instrukcí. ### Co porovnat před úpravou serverové kopie? Porovnejte uloženou větev a identifikátor commitu se zdrojovou kopií, prohlédněte necommitnuté změny a nechte Hermes ověřit skutečný pracovní adresář. Poté v této konkrétní kopii spusťte existující projektové kontroly. ## Ailoot · Společnost a její portfolio projektů Ailoot staví na dlouhodobých provozních zkušenostech, široké klientské základně, stabilních službách a průběžném sledování KPI. Společnost a její portfolio projektů: miliony zákazníků; měsíční tržby v miliardách. Ailoot využívá tyto provozní zkušenosti k poskytování přístupu přes API k funkcím AI v produktech zákazníků, agentech, aplikacích a automatizacích.