Flytta ett projekt från Codex till Hermes på en server

Om du behöver hjälp med tjänsten kan du läsa Ailoot-dokumentationen.

Vad du behöver förbereda inför överföringen#

Ett arkiv är en projektmapp med dess Git-ändringshistorik. En arbetskopia innehåller filerna du redigerar. Uppgiften här är att få över kopian till servern och fortsätta utvecklingen. Du behöver inte göra programmet tillgängligt för besökare ännu.

Om agenten ännu inte är installerad på servern börjar du med att installera Hermes Agent på en VPS. Här behöver du en fungerande Hermes-installation, serverns terminal och Git. Du behöver ett fjärrarkiv som är åtkomligt från servern. Om du inte har något ännu skapar du ett först och sparar projektet där utan hemligheter. För ett privat arkiv konfigurerar du läsåtkomst från ditt eget konto i förväg. Lägg inte en token i arkivets URL eller i ett meddelande till agenten.

Pausa parallella redigeringar av projektet under överföringen. Öppna en terminal i själva projektmappen på källdatorn och kör:

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

Det första kommandot visar grenen och filernas status. M betyder en ändring och ?? en fil som Git ännu inte spårar. I det andra kommandot markeras ignorerade filer med !!. En normal, ren status visar inte att du saknar nödvändiga filer utanför Git.

Spara de nödvändiga ändringarna i en separat commit och skicka upp rätt gren till fjärrarkivet på ditt vanliga sätt. Kontrollera vad commiten innehåller innan du skickar upp den: nycklar, lösenord och verkliga användardata får inte ingå. Om du inte vet vilka ändringar du ska spara ber du först Codex lista dem och förklara deras syfte, utan att ta bort filer eller skicka något till arkivet.

Utgå inte från att kloning av arkivet även överför en extern databas, innehållet i en ignorerad mapp eller dina samtal med Codex. Chatthistorik, prenumerationer, profiler och agenternas egna inställningar ingår inte i den här överföringsmetoden.

Kopiera rätt gren till servern#

Spara först resultatet från det här kommandot på källdatorn:

git status --porcelain=v2 --branch

Raden # branch.oid visar den aktuella commiten och # branch.head visar grenen. En commit är en sparad version av projektet. För ett typiskt projekt med befintliga commits gör detta det möjligt att jämföra källkopian med den nya kopian. Jämförelsen kontrollerar inte ocommiterade ändringar.

Gå till katalogen där du ska lagra dina projekt på servern. Klona arkivet till en ny mapp. I mallen nedan ersätter du REPOSITORY_URL med arkivets URL, BRANCH_NAME med namnet på grenen du sparat och skickat upp och my-project med namnet du vill ge den nya mappen:

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

Det här är en mall, inte en färdig URL att kopiera. git clone skapar en mapp och en arbetskopia av den valda grenen. Om målmappen redan finns måste den vara tom: ta inte bort innehållet för att köra kommandot igen, utan välj ett nytt namn.

Jämför # branch.oid i båda kopiorna. Om värdena skiljer sig ska du inte börja rätta kod på servern. Kontrollera den valda grenen, vilka commits du skickade upp och om parallella ändringar gjordes. Om statusen visar ändrade filer ska du undersöka dem separat. Använd inte rensning eller en tvingad återställning för att ”få dem att stämma överens”.

Arkiv med Git-submoduler – nästlade arkiv – kräver också att du hämtar deras innehåll. git clone har alternativet --recurse-submodules för detta. Använd det om projektet faktiskt innehåller submoduler och deras URL:er har kontrollerats. Projekt med andra externa resurser kan kräva en ytterligare procedur som beskrivs i README-filen.

Återställ beroenden enligt projektets regler#

Läs först README-filen och projektets konfigurationsfiler. Ta reda på vilken runtime-version som krävs och vilken pakethanterare som används för att installera beroenden. Byt inte ut projektets vanliga verktyg mot npm bara för att det förekommer i exemplet nedan.

Ett hypotetiskt exempel för Node.js och npm: arkivet har konsekventa package.json- och package-lock.json-filer, och en version av Node.js som passar projektet är installerad på servern. I så fall kör du detta i projektmappen:

npm ci

Enligt dokumentationen för npm ci installerar kommandot beroenden för hela projektet från låsfilen utan att skriva om package.json eller package-lock.json. Om innehållet i dem inte stämmer överens misslyckas installationen. En befintlig node_modules-mapp tas bort före installationen.

Om låsfilen skapades med alternativ som påverkar beroendeträdet, till exempel --legacy-peer-deps, behöver npm ci använda samma alternativ. Kontrollera källprojektets instruktioner och inställningar. Ta inte bort låsfilen och uppdatera inte alla beroenden för att dölja det första överföringsfelet.

Kontrollera installations- och startkommandona i ditt eget projekt innan du installerar. Kör dem i en separat arbetskopia utan åtkomst till produktionsdata och ange eventuella nödvändiga miljövärden utanför chatt och Git. Använd testuppgifter med begränsade behörigheter när det är möjligt. Om projektet är beroende av en databas eller filer ska du först återställa en tillåten testdatamängd enligt instruktionerna. Identiska källfiler ersätter inte dessa data.

Kör de befintliga kontrollerna i README-filen efter installationen: tester och en byggprocess, om sådana finns. Kommandonamnen beror på projektet. Att beroendena installerades korrekt betyder inte att programmet fungerar ännu.

Öppna arbetskopian i Hermes#

Gå till den nya kopians rot i serverns terminal och starta den redan installerade agenten:

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

Här är /absolute/path/to/my-project en platshållare för projektets fullständiga sökväg. Kontrollera arbetskatalogen och miljön där terminalkommandon körs på Hermess startskärm. Den här startmetoden är avsedd för Hermess lokala terminalmiljö på servern. Om SSH eller Docker är konfigurerat kan agenten köra kommandon i en annan miljö. Kontrollera först vilken projektsökväg som är tillgänglig där.

Be agenten bekräfta sin faktiska arbetsmapp med terminalverktyget och läs sedan README-filen och projektinstruktionerna. Betrakta inte ett mappnamn i ett meddelande som tillräcklig verifiering.

Ordningen nedan anges i en fastlåst dokumentationsversion och kan skilja sig från den Hermes-version du har installerad. Kontrollera de aktuella instruktionerna i din session. Hermes stöder AGENTS.md, men om den läser den filen beror på prioritetsordningen för kontextfiler. Enligt Hermes officiella dokumentation väljs en typ av instruktionsfil: .hermes.md, sedan AGENTS.override.md, AGENTS.md, CLAUDE.md och .cursorrules. Kontrollera om det finns en gammal .hermes.md eller en personlig AGENTS.override.md innan du börjar arbeta. Utgå inte från att agenten nödvändigtvis tillämpar AGENTS.md samtidigt med den.

Behåll projektets syfte, kontrollkommandon och begränsningar för ändringar i de valda instruktionerna. Gör dem inte till ett arkiv över samtal. Om du behöver överföra agenternas inställningar är det en annan process; dess omfattning förklaras i guiden för migrering från Claude Code till Codex.

Ge agenten en uppgift och kontrollera resultatet#

Börja med att läsa projektet utan att göra ändringar. Till exempel:

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.

Kom sedan överens om en liten uppgift, till exempel att rätta text i gränssnittet. Ange vilka filer eller vilket område som ska ändras och förbjud oavsiktliga uppdateringar av beroenden. Om du vill hålla experimentet åtskilt från huvudkopian kan du först läsa om en separat arbetskopia med Git worktree.

Godkänn resultatet utifrån filändringarna och upprepade projektkontroller. Spara källkopian och en återställningspunkt före ett experiment som kan misslyckas. Be inte agenten återställa alla ändringar på en gång. Om en kontroll misslyckas jämför du felet med källkopian. Det hjälper dig att skilja ett överföringsproblem från ett fel som redan fanns.

Överföringen kan anses slutförd när den nödvändiga versionen av källfilerna finns på plats, miljön har återställts, nödvändiga data finns i en säker testmiljö, kontrollerna godkänns och Hermes arbetar i just den här mappen. Att publicera programmet för besökare är ett separat nästa steg och ingår inte i den här kontrollen.

Lär känna Ailoot.