Flyt et projekt fra Codex til Hermes på en server

Se Ailoot-dokumentationen, hvis du har brug for hjælp til tjenesten.

Hvad du skal forberede inden overførslen#

Et repository er en projektmappe med dens Git-ændringshistorik. En arbejdskopi indeholder de filer, du redigerer. Opgaven her er at få kopien over på serveren og fortsætte udviklingen. Du behøver ikke gøre programmet tilgængeligt for besøgende endnu.

Hvis agenten endnu ikke er installeret på serveren, skal du begynde med at installere Hermes Agent på en VPS. Her skal du bruge en fungerende Hermes-installation, serverens terminal og Git. Du skal bruge et fjernrepository, som serveren har adgang til. Hvis du ikke har et endnu, skal du først oprette et og gemme projektet dér uden hemmeligheder. Hvis repository'et er privat, skal du på forhånd konfigurere læseadgang fra din egen konto. Læg ikke et token i repository'ets URL eller i en besked til agenten.

Sæt parallelle redigeringer af projektet på pause under overførslen. Åbn en terminal i selve projektmappen på kildecomputeren, og kør:

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

Den første kommando viser branchen og filernes tilstand. M betyder en ændring, og ?? betyder en fil, som Git endnu ikke sporer. I den anden kommando er ignorerede filer markeret med !!. En normal, ren status viser ikke, om du mangler nødvendige filer uden for Git.

Gem de nødvendige ændringer i en separat commit, og push den rigtige branch til dit fjernrepository på den sædvanlige måde. Kontrollér, hvad committet indeholder, inden du pusher: nøgler, adgangskoder og rigtige brugerdata må ikke være med. Hvis du ikke ved, hvilke ændringer du skal gemme, skal du først bede Codex om at opremse dem og forklare deres formål, uden at slette filer eller pushe til repository'et.

Gå ikke ud fra, at kloning af repository'et overfører en ekstern database, indholdet af en ignoreret mappe eller dine samtaler med Codex. Chathistorik, abonnementer, profiler og agenternes egne indstillinger indgår ikke i denne overførselsmetode.

Kopiér den rigtige branch til serveren#

Gem først outputtet fra denne kommando på kildecomputeren:

git status --porcelain=v2 --branch

Linjen # branch.oid viser det aktuelle commit, og # branch.head viser branchen. Et commit er en gemt version af projektet. For et typisk projekt med eksisterende commits gør dette det muligt at sammenligne kildekopien og den nye kopi; sammenligningen kontrollerer ikke ikke-committede ændringer.

Gå til den mappe på serveren, hvor du vil gemme dine projekter. Klon dit repository til en ny mappe. I skabelonen nedenfor skal du erstatte REPOSITORY_URL med URL'en til dit repository, BRANCH_NAME med navnet på den branch, du har gemt og pushet, og my-project med det navn, du vil give den nye mappe:

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

Dette er en skabelon, ikke en færdig URL, du kan kopiere. git clone opretter en mappe og en arbejdskopi af den valgte branch. Hvis destinationsmappen allerede findes, skal den være tom: slet ikke indholdet for at køre kommandoen igen; vælg et nyt navn.

Sammenlign # branch.oid i begge kopier. Hvis værdierne er forskellige, skal du ikke begynde at rette kode på serveren: kontrollér den valgte branch, de commits, du pushede, og om der blev foretaget parallelle ændringer. Hvis statusoutputtet viser ændrede filer, skal du undersøge dem separat. Brug ikke oprydning eller en tvungen nulstilling for at "få dem til at stemme overens".

Repositories med Git-submoduler – indlejrede repositories – kræver også, at du henter deres indhold. git clone har indstillingen --recurse-submodules til det; brug den, hvis projektet faktisk indeholder submoduler, og deres URL'er er blevet kontrolleret. Projekter med andre eksterne ressourcer kan kræve en yderligere procedure, som er beskrevet i README'en.

Gendan afhængigheder efter projektets regler#

Læs først README'en og projektets konfigurationsfiler. Find ud af, hvilken runtime-version der kræves, og hvilken pakkehåndtering der bruges til at installere afhængigheder. Erstat ikke projektets sædvanlige værktøj med npm, blot fordi det optræder i eksemplet nedenfor.

Et hypotetisk eksempel med Node.js og npm: Repository'et har konsistente package.json- og package-lock.json-filer, og en Node.js-version, der passer til projektet, er installeret på serveren. I så fald skal du køre dette i projektmappen:

npm ci

Ifølge dokumentationen til npm ci installerer kommandoen afhængigheder for hele projektet fra lockfilen uden at omskrive package.json eller package-lock.json. Hvis indholdet i dem ikke stemmer overens, mislykkes installationen. En eksisterende node_modules-mappe slettes inden installationen.

Hvis lockfilen blev oprettet med indstillinger, der påvirker afhængighedstræet, f.eks. --legacy-peer-deps, skal npm ci bruge de samme indstillinger. Kontrollér kildeprojektets instruktioner og indstillinger. Slet ikke lockfilen, og opdatér ikke alle afhængigheder for at skjule den første overførselsfejl.

Kontrollér installations- og opstartskommandoerne i dit eget projekt, inden du installerer. Kør dem i en separat arbejdskopi uden adgang til produktionsdata, og angiv eventuelle nødvendige miljøværdier uden for chat og Git. Brug om muligt testlegitimationsoplysninger med begrænsede tilladelser til at kontrollere projektet. Hvis projektet afhænger af en database eller filer, skal du først gendanne et tilladt testsæt efter instruktionerne; identiske kildefiler erstatter ikke disse data.

Kør de eksisterende kontroller fra README'en efter installationen: tests og et build, hvis det er angivet. Kommandonavnene afhænger af projektet. En vellykket installation af afhængigheder betyder endnu ikke, at programmet virker.

Åbn arbejdskopien i Hermes#

Gå til roden af den nye kopi i serverens terminal, og start den agent, der allerede er installeret:

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

Her er /absolute/path/to/my-project en pladsholder for den fulde sti til dit projekt. Kontrollér arbejdsbiblioteket og det miljø, hvor terminalkommandoerne kører, på Hermeses opstartsskærm. Denne opstartsmetode er beregnet til Hermeses lokale terminalmiljø på serveren. Hvis SSH eller Docker er konfigureret, kan agenten køre kommandoer i et andet miljø; bekræft først, hvilken projektsti der er tilgængelig dér.

Bed agenten om at bekræfte sin faktiske arbejdsmappe ved hjælp af terminalværktøjet, og læs derefter README'en og projektinstruktionerne. Betragt ikke et mappenavn i en besked som tilstrækkelig bekræftelse.

Rækkefølgen nedenfor er angivet i en fastlåst dokumentationsversion og kan afvige fra din installerede Hermes-version. Kontrollér de aktuelle instruktioner i din session. Hermes understøtter AGENTS.md, men om den læser filen afhænger af prioriteringen af kontekstfiler. Ifølge Hermes' officielle dokumentation vælges én type instruktionsfil: .hermes.md, derefter AGENTS.override.md, AGENTS.md, CLAUDE.md og .cursorrules. Kontrollér, om der findes en gammel .hermes.md eller en personlig AGENTS.override.md, inden du begynder at arbejde: gå ikke ud fra, at agenten nødvendigvis anvender AGENTS.md sammen med den.

Bevar projektets formål, kontrolkommandoer og begrænsninger for ændringer i de valgte instruktioner. Lav dem ikke om til et arkiv over samtaler. Hvis du også skal overføre agenternes indstillinger, er det en anden proces; dens omfang forklares i vejledningen til migrering fra Claude Code til Codex.

Giv agenten én opgave, og kontrollér resultatet#

Begynd med at læse projektet uden at foretage ændringer. For eksempel:

We are working with an existing project in the folder I specified.
Confirm the actual working directory using the terminal tool.
Read the README and the current project instructions.
Do not open files containing secrets or print environment values.
List the check commands and the prerequisites for running them.
For now, do not change or install anything, or push to the repository.

Aftal derefter én lille opgave, f.eks. at rette tekst i brugerfladen. Angiv de filer eller det område, der skal ændres, og forbyd utilsigtede opdateringer af afhængigheder. Hvis du vil holde eksperimentet adskilt fra hovedkopien, kan du først læse om en separat arbejdskopi med Git worktree.

Godkend resultatet ud fra filændringerne og gentagne projektkontroller. Gem kildekopien og et gendannelsespunkt inden et eksperiment, der kan mislykkes; bed ikke agenten om at nulstille alle ændringer på én gang. Hvis en kontrol fejler, skal du sammenligne fejlen med kildekopien: det hjælper med at skelne et overførselsproblem fra en fejl, der allerede fandtes.

Overførslen kan betragtes som fuldført, når den nødvendige version af kildefilerne er på plads, miljøet er gendannet, de nødvendige data er tilgængelige i et sikkert testmiljø, kontrollerne består, og Hermes arbejder i præcis denne mappe. At offentliggøre programmet for besøgende er et separat næste trin og indgår ikke i denne kontrol.

Lær Ailoot at kende.