Flytte et prosjekt fra Codex til Hermes på en server

Se Ailoot-dokumentasjonen for hjelp med å bruke tjenesten.

Hva du bør klargjøre før overføringen#

Et repository er en prosjektmappe med Git-endringshistorikken. En arbeidskopi inneholder filene du redigerer. Oppgaven her er å få denne kopien over på serveren og fortsette utviklingen. Du trenger ikke å gjøre applikasjonen tilgjengelig for besøkende ennå.

Hvis agenten ennå ikke er installert på serveren, begynner du med å installere Hermes Agent på en VPS. Her trenger du en fungerende Hermes-installasjon, serverterminalen og Git. Du trenger også et eksternt repository som er tilgjengelig fra serveren. Hvis du ikke har et ennå, oppretter du det først og lagrer prosjektet der uten hemmeligheter. For et privat repository konfigurerer du lesetilgang fra din egen konto på forhånd. Ikke legg et token i URL-en til repositoryet eller i en melding til agenten.

Sett parallelle endringer i prosjektet på pause under overføringen. Åpne en terminal på kildecomputeren i selve prosjektmappen, og kjør:

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

Den første kommandoen viser branchen og filenes tilstand. M betyr en endring, og ?? betyr en fil som Git ennå ikke sporer. I den andre kommandoen er ignorerte filer markert med !!. En vanlig ren status beviser ikke at du ikke har nødvendige filer utenfor Git.

Lagre de nødvendige endringene i en egen commit, og push riktig branch til det eksterne repositoryet på vanlig måte. Kontroller hva commiten inneholder før du pusher: nøkler, passord og faktiske brukerdata må ikke være med. Hvis du er usikker på hvilke endringer som skal lagres, ber du først Codex om å liste dem og forklare formålet, uten å slette filer eller pushe til repositoryet.

Ikke anta at kloning av repositoryet overfører en ekstern database, innholdet i en ignorert mappe eller samtalene dine med Codex. Chattehistorikk, abonnementer, profiler og agentenes egne innstillinger inngår ikke i denne overføringsmetoden.

Kopier riktig branch til serveren#

Lagre først resultatet av denne kommandoen på kildecomputeren:

git status --porcelain=v2 --branch

Linjen # branch.oid viser gjeldende commit, og # branch.head viser branchen. En commit er en lagret versjon av prosjektet. For et typisk prosjekt med eksisterende commiter gjør dette det mulig å sammenligne kildekopien med den nye kopien. Sammenligningen kontrollerer ikke endringer som ikke er committet.

Gå til katalogen der du vil lagre prosjektene dine på serveren. Klon repositoryet til en ny mappe. I malen nedenfor erstatter du REPOSITORY_URL med URL-en til repositoryet, BRANCH_NAME med navnet på branchen du lagret og pushet, og my-project med navnet du vil gi den nye mappen:

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

Dette er en mal, ikke en ferdig URL du kan kopiere. git clone oppretter en mappe og en arbeidskopi av den valgte branchen. Hvis målmappen allerede finnes, må den være tom. Ikke slett innholdet for å kjøre kommandoen på nytt; velg et nytt navn.

Sammenlign # branch.oid i begge kopiene. Hvis verdiene er forskjellige, må du ikke begynne å rette kode på serveren. Kontroller den valgte branchen, commitene du pushet, og om det ble gjort parallelle endringer. Hvis statusresultatet viser endrede filer, undersøker du dem separat. Ikke bruk opprydding eller en tvungen reset for å «få dem til å stemme».

Repositories med Git-submoduler – nestede repositories – krever også at du henter innholdet deres. git clone har et --recurse-submodules-alternativ for dette. Bruk det hvis prosjektet faktisk inneholder submoduler og URL-ene deres er kontrollert. Prosjekter med andre eksterne ressurser kan kreve en tilleggsprosedyre som er beskrevet i README.

Gjenopprett avhengighetene i tråd med prosjektets regler#

Les først README og prosjektets konfigurasjonsfiler. Finn ut hvilken runtime-versjon som kreves, og hvilken pakkebehandler som brukes til å installere avhengigheter. Ikke bytt ut prosjektets vanlige verktøy med npm bare fordi det vises i eksemplet nedenfor.

Et hypotetisk eksempel for Node.js og npm: Repositoryet har konsistente package.json- og package-lock.json-filer, og en versjon av Node.js som passer til prosjektet, er installert på serveren. Kjør i så fall dette i prosjektmappen:

npm ci

Ifølge dokumentasjonen for npm ci installerer kommandoen avhengigheter for hele prosjektet fra lockfilen uten å skrive om package.json eller package-lock.json. Hvis innholdet i filene ikke stemmer overens, mislykkes installasjonen. En eventuell eksisterende node_modules-mappe slettes før installasjonen.

Hvis lockfilen ble opprettet med alternativer som påvirker avhengighetstreet, for eksempel --legacy-peer-deps, må npm ci bruke de samme alternativene. Kontroller instruksjonene og innstillingene i kildeprosjektet. Ikke slett lockfilen eller oppdater alle avhengighetene for å skjule den første overføringsfeilen.

Kontroller installasjons- og oppstartskommandoene i ditt eget prosjekt før du installerer. Kjør dem i en separat arbeidskopi uten tilgang til produksjonsdata, og angi eventuelle nødvendige miljøverdier utenfor chat og Git. Bruk testlegitimasjon med begrensede rettigheter til å kontrollere prosjektet når det er mulig. Hvis prosjektet er avhengig av en database eller filer, gjenoppretter du først et tillatt testdatasett i tråd med instruksjonene. Identiske kildefiler kan ikke erstatte disse dataene.

Etter installasjonen kjører du de eksisterende kontrollene fra README: tester og en build, hvis dette er oppgitt. Kommandonavnene avhenger av prosjektet. At avhengighetene ble installert, betyr ikke i seg selv at applikasjonen fungerer.

Åpne arbeidskopien i Hermes#

Gå til roten av den nye kopien i serverterminalen, og start agenten som allerede er installert:

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

Her er /absolute/path/to/my-project en plassholder for den fullstendige stien til prosjektet ditt. Kontroller arbeidskatalogen og miljøet der terminalkommandoene kjøres, på oppstartsskjermen i Hermes. Denne oppstartsmetoden er beregnet på Hermes sitt lokale terminalmiljø på serveren. Hvis SSH eller Docker er konfigurert, kan agenten kjøre kommandoer i et annet miljø. Kontroller først at prosjektstien er tilgjengelig der.

Be agenten bekrefte den faktiske arbeidsmappen ved hjelp av terminalverktøyet, og les deretter README og prosjektinstruksjonene. Ikke betrakt et mappenavn i en melding som tilstrekkelig bekreftelse.

Rekkefølgen nedenfor står i en versjon av dokumentasjonen som er låst til et bestemt tidspunkt, og kan avvike fra Hermes-versjonen du har installert. Kontroller gjeldende instruksjoner i økten din. Hermes støtter AGENTS.md, men om den leser filen, avhenger av prioriteringen mellom kontekstfiler. Ifølge den offisielle Hermes-dokumentasjonen velges én type instruksjonsfil: først .hermes.md, deretter AGENTS.override.md, AGENTS.md, CLAUDE.md og .cursorrules. Se etter en gammel .hermes.md eller en personlig AGENTS.override.md før du starter. Ikke anta at agenten nødvendigvis bruker AGENTS.md som ligger ved siden av.

Behold prosjektets formål, kontrollkommandoer og begrensninger for endringer i de valgte instruksjonene. Ikke gjør dem om til et arkiv over samtaler. Hvis du også må overføre agentenes egne innstillinger, er det en annen prosess. Omfanget forklares i veiledningen for migrering fra Claude Code til Codex.

Gi agenten én oppgave og kontroller resultatet#

Begynn med å lese prosjektet uten å gjøre endringer. For eksempel:

Vi jobber med et eksisterende prosjekt i mappen jeg har angitt.
Bekreft den faktiske arbeidsmappen ved hjelp av terminalverktøyet.
Les README og de gjeldende prosjektinstruksjonene.
Ikke åpne filer som inneholder hemmeligheter, eller skriv ut miljøvariabler.
List opp kontrollkommandoene og forutsetningene for å kjøre dem.
Ikke endre eller installer noe foreløpig, og ikke push til repositoryet.

Avtal deretter én liten oppgave, for eksempel å rette tekst i grensesnittet. Oppgi hvilke filer eller hvilket område som skal endres, og forby utilsiktede oppdateringer av avhengigheter. Hvis du vil skille forsøket fra hovedkopien, bør du først lese om en separat Git-worktree-arbeidskopi.

Godta resultatet basert på filendringene og gjentatte prosjektkontroller. Før et forsøk som kan mislykkes, lagrer du kildekopien og et gjenopprettingspunkt. Ikke be agenten om å tilbakestille alle endringene i én operasjon. Hvis en kontroll mislykkes, sammenligner du feilen med kildekopien. Dette bidrar til å skille et overføringsproblem fra en feil som allerede fantes.

Overføringen kan regnes som fullført når den nødvendige versjonen av kildefilene er på plass, miljøet er gjenopprettet, nødvendige data er tilgjengelige i et trygt testmiljø, kontrollene består, og Hermes arbeider i akkurat denne mappen. Å publisere applikasjonen for besøkende er en separat neste fase og inngår ikke i denne kontrollen.

Bli kjent med Ailoot.