Blog

Projekt áthelyezése a Codexből a Hermesbe egy szerveren

Markdown

Adattár átvitele szerverre a Hermesben végzett munkához: mentett módosítások, függőségek, titkok, munkamappa és a fejlesztés folytatása előtti ellenőrzések.

A teljes cikk elolvasása

A szolgáltatás használatával kapcsolatos segítségért tekintse meg az Ailoot dokumentációját.

Fő üzenet

Ha a Codexszel létrehozott projekten a Hermesben szeretné folytatni a munkát, vigye át magát az adattárat, és állítsa helyre a környezetét. Ehhez a módszerhez nincs szükség külön, „projekt importálása egy ügynöktől” lépésre. Először ellenőrizze a mentett fájlokat és a függőségeket, majd nyissa meg a megfelelő mappát a Hermesben. Ez az útmutató feltételezi, hogy a szerver és a Hermes már be van állítva, és Ön hozzáfér az adattárhoz.

Mit készítsen elő az átvitel előtt

Az adattár egy projektmappa a Git módosítási előzményeivel együtt. A munkapéldány az Ön által szerkesztett fájlokat tartalmazza. A feladat az, hogy ez a példány átkerüljön a szerverre, és ott folytatódjon a fejlesztés. Az alkalmazást egyelőre nem kell elérhetővé tennie a látogatók számára.

Ha az ügynök még nincs telepítve a szerverre, kezdje a Hermes Agent VPS-re történő telepítésével. Ehhez az útmutatóhoz működő Hermes-telepítésre, a szerver termináljára és Gitre lesz szüksége. Olyan távoli adattárra van szüksége, amely a szerverről elérhető; ha még nincs ilyenje, először hozza létre, és mentse oda a projektet titkok nélkül. Privát adattár esetén előre állítsa be a saját fiókjából történő olvasási hozzáférést; ne tegyen tokent az adattár URL-jébe vagy az ügynöknek küldött üzenetbe.

Az átvitel idejére szüneteltesse a projekt párhuzamos szerkesztését. A forrásgépen nyisson terminált közvetlenül a projekt mappájában, majd futtassa:

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

Az első parancs megjeleníti az ágat és a fájlok állapotát. Az M módosítást, a ?? pedig olyan fájlt jelöl, amelyet a Git még nem követ. A második parancsban a figyelmen kívül hagyott fájlokat !! jelöli. A szokásos tiszta állapot nem bizonyítja, hogy a Giten kívül nincs szükséges fájlja.

Mentse a szükséges módosításokat külön commitba, majd a szokásos módon pusholja a megfelelő ágat a távoli adattárba. Push előtt ellenőrizze, mi kerül a commitba: kulcsok, jelszavak és valódi felhasználói adatok nem szerepelhetnek benne. Ha nem tudja, mely módosításokat kell elmentenie, először kérje meg a Codexet, hogy sorolja fel őket, és magyarázza el a céljukat; fájlok törlése vagy az adattárba történő push nélkül.

A projekt részeMit ellenőrizzen az átvitel előtt
Forrásfájlok és Git-előzményekA szükséges módosítások el vannak mentve, és elérhetők a távoli adattár kiválasztott ágában
README és ügynöki utasításokAz indítási lépések, ellenőrzések és korlátozások dokumentálva vannak; az utasítások naprakészek
Függőségi fájlokA függőségek meghatározásai és a projekt által használt lockfile – a verziókat rögzítő fájl – el vannak mentve
TitkokVan külön, biztonságos mód ezek beállítására a szerveren; az értékeik nincsenek a Gitben, és nem küldik el őket chaten
Adatbázis és feltöltött fájlokTudja, honnan szerezhet engedélyezett tesztadatokat, és hogyan állíthatja helyre őket a projekt utasításai szerint

Ne feltételezze, hogy az adattár klónozása átvisz egy külső adatbázist, egy figyelmen kívül hagyott mappa tartalmát vagy a Codexszel folytatott beszélgetéseit. A csevegési előzmények, előfizetések, profilok és az ügynökök saját beállításai nem részei ennek az átviteli módszernek.

A megfelelő ág másolása a szerverre

Először mentse el ennek a parancsnak a kimenetét a forrásgépen:

git status --porcelain=v2 --branch

A # branch.oid sor az aktuális commitot, a # branch.head pedig az ágat mutatja. A commit a projekt mentett verziója. Egy már commitokat tartalmazó tipikus projekt esetén így összehasonlíthatja a forrás- és az új példányt; ez az összehasonlítás a nem commitolt módosításokat nem ellenőrzi.

A szerveren lépjen abba a könyvtárba, ahol a projektjeit tárolni fogja. Klónozza az adattárat egy új mappába. Az alábbi sablonban cserélje le a REPOSITORY_URL értékét az adattár URL-jére, a BRANCH_NAME értékét annak az ágnak a nevére, amelyet elmentett és pusholt, a my-project értékét pedig az új mappa kívánt nevére:

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

Ez sablon, nem egy kész URL, amelyet csak be kell másolni. A git clone létrehoz egy mappát és a kiválasztott ág munkapéldányát. Ha a célmappa már létezik, üresnek kell lennie: ne törölje a tartalmát a parancs újbóli futtatásához; válasszon új nevet.

Hasonlítsa össze a # branch.oid értékét a két példányban. Ha az értékek eltérnek, ne kezdje el a kód javítását a szerveren: ellenőrizze a kiválasztott ágat, azokat a commitokat, amelyeket pusholt, és hogy történtek-e párhuzamos módosítások. Ha az állapotkimenet módosított fájlokat jelez, vizsgálja meg őket külön. Ne takarítással vagy kényszerített resettel próbálja „azonossá tenni” őket.

A Git almodulokat – beágyazott adattárakat – tartalmazó adattárak esetében azok tartalmát is le kell kérnie. Ehhez a git clone rendelkezik a --recurse-submodules kapcsolóval; akkor használja, ha a projekt valóban tartalmaz almodulokat, és ellenőrizte az URL-jeiket. Más külső erőforrásoktól függő projektekhez további, a README-ben leírt eljárásra is szükség lehet.

A függőségek helyreállítása a projekt szabályai szerint

Először olvassa el a README-t és a projekt konfigurációs fájljait. Nézze meg, melyik futtatókörnyezet-verzióra van szükség, és melyik csomagkezelővel telepítik a függőségeket. Ne cserélje le a projekt szokásos eszközét npm-re csak azért, mert az alábbi példában ez szerepel.

Feltételezett példa Node.js és npm használatára: az adattárban a package.json és a package-lock.json fájlok összhangban vannak, a szerveren pedig a projekthez megfelelő Node.js-verzió van telepítve. Ebben az esetben futtassa ezt a projekt mappájában:

npm ci

Az npm ci dokumentációja szerint a parancs a lockfile alapján telepíti a függőségeket a teljes projekthez, anélkül hogy újraírná a package.json vagy a package-lock.json fájlt. Ha a tartalmuk nem egyezik, a telepítés meghiúsul. A már meglévő node_modules mappát a telepítés előtt törli.

Ha a lockfile olyan kapcsolókkal készült, amelyek befolyásolják a függőségi fát, például a --legacy-peer-deps kapcsolóval, az npm ci ugyanazokat a kapcsolókat igényli. Ellenőrizze a forrásprojekt utasításait és beállításait. Ne törölje a lockfile-t, és ne frissítsen minden függőséget az első átviteli hiba elfedése érdekében.

Telepítés előtt ellenőrizze a saját projektjének telepítési és indítási parancsait. Futtassa őket külön munkapéldányban, amely nem fér hozzá az éles adatokhoz, a szükséges környezeti értékeket pedig a chaten és a Giten kívül állítsa be. A projekt ellenőrzéséhez lehetőség szerint korlátozott jogosultságú teszt-hitelesítő adatokat használjon. Ha a projekt adatbázistól vagy fájloktól függ, előbb állítson helyre egy engedélyezett tesztadatkészletet az utasításai szerint; az azonos forrásfájlok nem helyettesítik ezeket az adatokat.

A telepítés után futtassa a README-ben felsorolt meglévő ellenőrzéseket: a teszteket és a buildet, ha vannak ilyenek. A parancsok neve projektenként eltér. A függőségek sikeres telepítése önmagában még nem jelenti azt, hogy az alkalmazás működik.

A munkapéldány megnyitása a Hermesben

A szerver termináljában lépjen az új példány gyökerébe, és indítsa el a már telepített ügynököt:

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

Itt az /absolute/path/to/my-project a projekt teljes elérési útjának helyőrzője. A Hermes indítóképernyőjén ellenőrizze a munkakönyvtárat és azt a környezetet, amelyben a terminálparancsok futnak. Ez az indítási módszer a Hermes szerveren futó helyi terminálkörnyezetéhez készült. Ha az SSH vagy a Docker be van állítva, az ügynök egy másik környezetben is futtathat parancsokat; előbb ellenőrizze, hogy ott milyen projektútvonal érhető el.

Kérje meg az ügynököt, hogy a termináleszközével erősítse meg a tényleges munkamappáját, majd olvassa el a README-t és a projektutasításokat. Egy üzenetben szereplő mappanév önmagában nem elegendő ellenőrzés.

Az alábbi sorrend a dokumentáció rögzített verziójában szerepel, és eltérhet az Ön által telepített Hermes verziójától. Ellenőrizze a munkamenet aktuális utasításait. A Hermes támogatja az AGENTS.md fájlt, de hogy beolvassa-e, az a környezetifájlok prioritási sorrendjétől függ. A Hermes hivatalos dokumentációja szerint egy utasításfájl-típus kerül kiválasztásra, ebben a sorrendben: .hermes.md, AGENTS.override.md, AGENTS.md, CLAUDE.md, majd .cursorrules. A munka megkezdése előtt ellenőrizze, van-e régi .hermes.md vagy személyes AGENTS.override.md fájl: ne feltételezze, hogy az ügynök feltétlenül alkalmazni fogja az ezek mellett található AGENTS.md fájlt.

A kiválasztott utasításokban őrizze meg a projekt célját, ellenőrző parancsait és a módosításokra vonatkozó korlátozásokat. Ne alakítsa őket beszélgetési archívummá. Ha magukat az ügynökbeállításokat is át kell vinnie, az másik folyamat; ennek hatókörét a Claude Code-ról Codexre történő migráció útmutatója ismerteti.

Adjon egy feladatot az ügynöknek, majd ellenőrizze az eredményt

Kezdje a projekt elolvasásával, módosítások nélkül. Például:

Egy meglévő projekttel dolgozunk az általam megadott mappában.
Erősítse meg a tényleges munkakönyvtárat a termináleszközzel.
Olvassa el a README-fájlt és az aktuális projektutasításokat.
Ne nyisson meg titkokat tartalmazó fájlokat, és ne jelenítsen meg környezeti változókat.
Sorolja fel az ellenőrző parancsokat és a futtatásuk előfeltételeit.
Egyelőre ne módosítson vagy telepítsen semmit, és ne pusholjon az adattárba.

Ezután állapodjanak meg egy kis feladatban, például egy felületi szöveg javításában. Adja meg, mely fájlokon vagy területen dolgozzon, és tiltsa meg a nem kapcsolódó függőségfrissítéseket. Ha a kísérletet el szeretné különíteni a fő munkapéldánytól, előbb tájékozódjon a külön Git worktree munkapéldányról.

A fájlmódosítások és a projekt ellenőrzéseinek megismétlése alapján fogadja el az eredményt. Egy esetleg sikertelen kísérlet előtt mentse el a forráspéldányt és egy helyreállítási pontot; ne kérje az ügynöktől az összes módosítás tömeges visszaállítását. Ha egy ellenőrzés sikertelen, vesse össze a hibát a forráspéldánnyal: ez segít megkülönböztetni az átviteli problémát egy már korábban is fennálló hibától.

Az átvitel akkor tekinthető befejezettnek, ha a szükséges forrásfájl-verzió a helyén van, a környezet helyreállt, a szükséges adatok biztonságos tesztkörnyezetben rendelkezésre állnak, az ellenőrzések sikeresek, és a Hermes pontosan ebben a mappában dolgozik. Az alkalmazás látogatók számára történő közzététele külön következő lépés, és nem része ennek az ellenőrzésnek.

Ismerje meg az Ailootot.

További részletek

Kérdések és válaszok: Projekt áthelyezése a Codexből a Hermesbe egy szerveren

A repository klónozása átviszi az egész munkakörnyezetet?

Nem. A Git-klónozás nem hozza át a kizárt fájlokat, külső adatbázisokat, feltöltött adatokat, titkokat vagy az ügynök chatelőzményeit. A szükséges függőségeket és engedélyezett tesztadatokat külön állítsd helyre a projektutasítások szerint.

Mit hasonlítsak össze a szerverpéldány szerkesztése előtt?

A mentett ág- és commitazonosítót vesd össze a forráspéldánnyal, nézd át a nem commitolt módosításokat, és a Hermesszel igazoltasd a tényleges munkakönyvtárát. Ezután pontosan abban a példányban futtasd a projekt meglévő ellenőrzéseit.

Összes cikk