# Premik projekta iz Codexa v Hermes na strežniku > Prenos repozitorija na strežnik za delo v Hermes: shranjene spremembe, odvisnosti, skrivnosti, delovna mapa in preverjanja pred nadaljevanjem razvoja. Source: https://ailoot.ai/blog/sl/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/sl/codex-project-to-hermes-server/ Language: sl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-be2bf9be842ebb7831a900e2081525ab67b23a01a2fad20c370c83ebad670443 Za pomoč pri uporabi storitve si oglejte [dokumentacijo Ailoot](https://ailoot.ai/docs/).
Ključna ugotovitev Če želite nadaljevati delo v Hermesu s projektom, ustvarjenim s Codexom, prenesite sam repozitorij in obnovite njegovo okolje. Za ta pristop ne potrebujete ločenega koraka »uvozi projekt iz agenta«. Najprej preverite shranjene datoteke in odvisnosti, nato v Hermesu odprite pravo mapo. Ta vodič predpostavlja, da sta strežnik in Hermes že nastavljena ter da imate dostop do repozitorija.
## 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](https://ailoot.ai/blog/sl/hermes-agent-vps-24-7/). 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: ```bash 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. | Del projekta | Kaj preveriti pred prenosom | |----|----| | Izvorne datoteke in zgodovina Git | Potrebne spremembe so shranjene in dostopne v izbrani veji oddaljenega repozitorija | | README in navodila za agenta | Koraki za zagon, preverjanja in omejitve so dokumentirani; navodila so posodobljena | | Datoteke odvisnosti | Definicije odvisnosti in lockfile, ki ga uporablja projekt – datoteka, ki določa različice – so shranjeni | | Skrivnosti | Obstaja ločen in varen način za njihovo nastavitev na strežniku; njihove vrednosti niso v Gitu ali poslane prek klepeta | | Zbirka podatkov in naložene datoteke | Veste, kje dobiti dovoljene testne podatke in kako jih obnoviti v skladu z navodili projekta | 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: ```bash 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: ```bash 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: ```bash npm ci ``` Kot navaja [dokumentacija ukaza npm ci](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md), 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: ```bash 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](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md) 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](https://ailoot.ai/blog/sl/migrate-claude-code-to-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](https://ailoot.ai/blog/sl/codex-worktree-separate-task/). 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](https://ailoot.ai/). ## Vprašanja in odgovori: Premik projekta iz Codexa v Hermes na strežniku ### Ali kloniranje repozitorija prenese celotno delovno okolje? Ne. Kloniranje Git ne prenese prezrtih datotek, zunanjih podatkovnih baz, naloženih podatkov, skrivnosti ali zgodovine klepetov agenta. Potrebne odvisnosti in dovoljene testne podatke obnovite ločeno po projektnih navodilih. ### Kaj primerjam pred urejanjem strežniške kopije? Shranjeno vejo in identifikator commita primerjajte z izvorno kopijo, preglejte nepotrjene spremembe in Hermesu naročite preverjanje dejanskega delovnega imenika. Nato v tej točni kopiji zaženite obstoječa projektna preverjanja. ## Ailoot · Podjetje in njegov portfelj projektov Ailoot temelji na pridobljenih operativnih izkušnjah, široki bazi strank, stabilni storitvi in stalnem spremljanju KPI. Podjetje in njegov portfelj projektov: milijoni strank; mesečna prodaja v milijardah. Ailoot te operativne izkušnje uporablja za dostop prek API do funkcij umetne inteligence v izdelkih strank, agentih, aplikacijah in avtomatizacijah.