Premik projekta iz Codexa v Hermes na strežniku

Za pomoč pri uporabi storitve si oglejte dokumentacijo Ailoot.

Kaj pripraviti pred prenosom#

Repozitorij je projektna mapa z zgodovino sprememb Git. Delovna kopija vsebuje datoteke, ki jih urejate. Naloga je prenesti to kopijo na strežnik in tam nadaljevati razvoj. Aplikacije vam še ni treba omogočiti obiskovalcem.

Če agent še ni nameščen na strežniku, najprej sledite navodilom za namestitev Hermes Agent na VPS. Potrebovali boste delujočo namestitev Hermesa, strežniški terminal in Git. Potrebujete oddaljeni repozitorij, ki je dostopen s strežnika; če ga še nimate, ga najprej ustvarite in vanj shranite projekt brez skrivnosti. Za zasebni repozitorij vnaprej nastavite dostop za branje iz svojega računa; žetona ne vstavljajte v URL repozitorija ali v sporočilo agentu.

Med prenosom začasno ustavite vzporedno urejanje projekta. V izvornem računalniku odprite terminal neposredno v projektni mapi in zaženite:

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

Prvi ukaz prikaže vejo in stanje datotek. M pomeni spremembo, ?? pa datoteko, ki je Git še ne sledi. V drugem ukazu so prezrte datoteke označene z !!. Običajno čisto stanje ne dokazuje, da zunaj Gita nimate potrebnih datotek.

Potrebne spremembe shranite v ločen commit in na običajen način potisnite ustrezno vejo v oddaljeni repozitorij. Pred potiskanjem preverite vsebino commita: ključi, gesla in resnični uporabniški podatki ne smejo biti vključeni. Če ne veste, katere spremembe shraniti, najprej prosite Codex, naj jih našteje in pojasni njihov namen, ne da bi izbrisal datoteke ali potisnil spremembe v repozitorij.

Ne predpostavljajte, da bo kloniranje repozitorija preneslo zunanjo zbirko podatkov, vsebino prezrte mape ali vaše pogovore s Codexom. Zgodovina klepetov, naročnine, profili in lastne nastavitve agentov niso del tega načina prenosa.

Kopirajte pravo vejo na strežnik#

Najprej shranite izpis tega ukaza v izvornem računalniku:

git status --porcelain=v2 --branch

Vrstica # branch.oid prikazuje trenutni commit, # branch.head pa vejo. Commit je shranjena različica projekta. Pri običajnem projektu z obstoječimi commiti lahko tako primerjate izvorno in novo kopijo; ta primerjava ne preverja nepotrjenih sprememb.

Na strežniku pojdite v imenik, kamor boste shranili projekte. Repozitorij klonirajte v novo mapo. V spodnji predlogi zamenjajte REPOSITORY_URL z URL-jem svojega repozitorija, BRANCH_NAME z imenom veje, ki ste jo shranili in potisnili, ter my-project z želenim imenom nove mape:

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

To je predloga, ne že pripravljen URL za kopiranje. git clone ustvari mapo in delovno kopijo izbrane veje. Če ciljna mapa že obstaja, mora biti prazna: ne izbrišite njene vsebine, da bi ukaz zagnali znova; izberite novo ime.

Primerjajte # branch.oid v obeh kopijah. Če se vrednosti razlikujeta, ne začnite popravljati kode na strežniku: preverite izbrano vejo, commite, ki ste jih potisnili, in ali so bile izvedene vzporedne spremembe. Če izpis stanja prikazuje spremenjene datoteke, jih raziščite ločeno. Ne uporabite čiščenja ali prisilne ponastavitve, da bi jih »uskladili«.

Repozitoriji s podmoduli Git – ugnezdenimi repozitoriji – zahtevajo tudi pridobitev njihove vsebine. git clone ima za to možnost --recurse-submodules; uporabite jo, če projekt dejansko vsebuje podmodule in ste preverili njihove URL-je. Projekti z drugimi zunanjimi viri lahko zahtevajo dodaten postopek, opisan v README.

Obnovite odvisnosti v skladu s pravili projekta#

Najprej preberite README in konfiguracijske datoteke projekta. Ugotovite, katera različica izvajalnega okolja je potrebna in kateri upravljalnik paketov se uporablja za namestitev odvisnosti. Običajnega orodja projekta ne zamenjajte z npm samo zato, ker je omenjeno v spodnjem primeru.

Hipotetični primer za Node.js in npm: repozitorij ima usklajeni datoteki package.json in package-lock.json, na strežniku pa je nameščena različica Node.js, primerna za projekt. V tem primeru zaženite ukaz v projektni mapi:

npm ci

Kot navaja dokumentacija ukaza npm ci, ukaz namesti odvisnosti za celoten projekt iz lockfile, ne da bi prepisal package.json ali package-lock.json. Če njuna vsebina ni usklajena, namestitev ne uspe. Pred namestitvijo se izbriše vsaka obstoječa mapa node_modules.

Če je bil lockfile ustvarjen z možnostmi, ki vplivajo na drevo odvisnosti, kot je --legacy-peer-deps, npm ci potrebuje iste možnosti. Preverite navodila in nastavitve izvornega projekta. Ne izbrišite lockfile in ne posodobite vseh odvisnosti, da bi prikrili prvo napako pri prenosu.

Pred namestitvijo preverite ukaze za namestitev in zagon v svojem projektu. Zaženite jih v ločeni delovni kopiji brez dostopa do produkcijskih podatkov, morebitne potrebne vrednosti okolja pa nastavite zunaj klepeta in Gita. Za preverjanje projekta, če je mogoče, uporabite testne poverilnice z omejenimi dovoljenji. Če je projekt odvisen od zbirke podatkov ali datotek, najprej obnovite dovoljeno testno zbirko podatkov v skladu z navodili; enake izvorne datoteke ne nadomestijo teh podatkov.

Po namestitvi zaženite obstoječa preverjanja iz README: teste in gradnjo, če sta na voljo. Imena ukazov so odvisna od projekta. Uspešna namestitev odvisnosti še ne pomeni, da aplikacija deluje.

Odprite delovno kopijo v Hermesu#

V strežniškem terminalu pojdite v korensko mapo nove kopije in zaženite že nameščenega agenta:

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

Tukaj je /absolute/path/to/my-project nadomestno besedilo za polno pot do vašega projekta. Na začetnem zaslonu Hermesa preverite delovni imenik in okolje, v katerem se izvajajo terminalski ukazi. Ta način zagona je namenjen lokalnemu terminalskemu okolju Hermesa na strežniku. Če je konfiguriran SSH ali Docker, lahko agent ukaze izvaja v drugem okolju; najprej potrdite, katera projektna pot je tam na voljo.

Prosite agenta, naj s svojim terminalskim orodjem potrdi dejansko delovno mapo, nato pa prebere README in navodila za projekt. Ime mape v sporočilu ne šteje kot zadostno preverjanje.

Spodnje zaporedje je navedeno v določeni različici dokumentacije in se lahko razlikuje od nameščene različice Hermesa. Preverite trenutna navodila v svoji seji. Hermes podpira AGENTS.md, vendar je njegovo branje odvisno od prednosti kontekstnih datotek. Po uradni dokumentaciji Hermesa se izbere ena vrsta datoteke z navodili, po tem vrstnem redu: .hermes.md, nato AGENTS.override.md, AGENTS.md, CLAUDE.md in .cursorrules. Pred začetkom dela preverite, ali obstaja star .hermes.md ali osebni AGENTS.override.md: ne predpostavljajte, da bo agent nujno upošteval AGENTS.md, ki je poleg njega.

V izbranih navodilih ohranite namen projekta, ukaze za preverjanje in omejitve sprememb. Ne spreminjajte jih v arhiv pogovorov. Če želite prenesti tudi same nastavitve agentov, je to drug postopek; njegov obseg je opisan v vodiču za selitev s Claude Code na Codex.

Agentu dodelite eno nalogo in preverite rezultat#

Začnite z branjem projekta, ne da bi karkoli spreminjali. Na primer:

Delamo z obstoječim projektom v mapi, ki sem jo določil.
S terminalskim orodjem potrdite dejanski delovni imenik.
Preberite README in trenutna navodila za projekt.
Ne odpirajte datotek s skrivnostmi in ne izpisujte vrednosti okolja.
Navedite ukaze za preverjanje in predpogoje za njihovo izvajanje.
Za zdaj ničesar ne spreminjajte ali nameščajte in ne potiskajte sprememb v repozitorij.

Nato se dogovorite za eno manjšo nalogo, na primer popravek besedila v uporabniškem vmesniku. Določite datoteke ali področje, ki naj se spremeni, in prepovejte nepovezane posodobitve odvisnosti. Če želite poskus ločiti od glavne kopije, se najprej seznanite z ločeno delovno kopijo Git worktree.

Rezultat sprejmite na podlagi sprememb datotek in ponovljenih preverjanj projekta. Pred poskusom, ki bi lahko bil neuspešen, shranite izvorno kopijo in obnovitveno točko; agentu ne naročite, naj množično ponastavi vse spremembe. Če preverjanje ne uspe, napako primerjajte z izvorno kopijo: tako boste lažje ločili težavo pri prenosu od napake, ki je obstajala že prej.

Prenos lahko štejete za končan, ko je na voljo zahtevana različica izvornih datotek, je okolje obnovljeno, so potrebni podatki na voljo v varnem testnem okolju, preverjanja uspejo in Hermes deluje prav v tej mapi. Objavljanje aplikacije za obiskovalce je ločena naslednja faza in ni del tega preverjanja.

Spoznajte Ailoot.