# Een project van Codex naar Hermes op een server verplaatsen > Verplaats je Codex-project naar een server voor Hermes: bewaar de juiste branch, herstel afhankelijkheden en geheimen en controleer de werkmap vóór je verdergaat. Source: https://ailoot.ai/blog/nl/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/nl/codex-project-to-hermes-server/ Language: nl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-8074792ba9c6bd47801b3a7ad7b3e8d5a563dc0dbe8f024b22692e8c7dfde965 Zie de [Ailoot-documentatie](https://ailoot.ai/docs/) voor hulp bij het gebruik van de dienst.
Belangrijkste conclusie Om in Hermes verder te werken aan een project dat met Codex is gemaakt, zet je de repository zelf over en herstel je de omgeving ervan. Voor deze aanpak is geen aparte stap nodig om een project van een agent te importeren. Controleer eerst de opgeslagen bestanden en afhankelijkheden en open daarna de juiste map in Hermes. Deze handleiding gaat ervan uit dat de server en Hermes al zijn ingesteld en dat je toegang hebt tot de repository.
## Wat je vóór de overdracht moet voorbereiden Een repository is een projectmap met de wijzigingsgeschiedenis van Git. Een werkkopie bevat de bestanden die je bewerkt. De taak hier is om die kopie op de server te krijgen en verder te gaan met ontwikkelen. Je hoeft de applicatie nog niet beschikbaar te maken voor bezoekers. Als de agent nog niet op de server is geïnstalleerd, begin dan met [Hermes Agent installeren op een VPS](https://ailoot.ai/blog/nl/hermes-agent-vps-24-7/). Je hebt hier een werkende Hermes-installatie, de serverterminal en Git nodig. Je hebt ook een externe repository nodig die vanaf de server bereikbaar is; als je die nog niet hebt, maak er dan eerst een aan en sla het project daar op zonder geheimen. Stel voor een private repository vooraf leestoegang in via je eigen account; zet geen token in de repository-URL of in een bericht aan de agent. Pauzeer parallelle wijzigingen aan het project tijdens de overdracht. Open op de broncomputer een terminal in de projectmap zelf en voer uit: ```bash git status --short --branch git status --short --ignored ``` Het eerste commando toont de branch en de status van de bestanden. `M` betekent een wijziging en `??` een bestand dat Git nog niet bijhoudt. In het tweede commando worden genegeerde bestanden aangeduid met `!!`. Een normale, schone status bewijst niet dat je buiten Git geen noodzakelijke bestanden hebt. Sla de noodzakelijke wijzigingen op in een aparte commit en push de juiste branch op de gebruikelijke manier naar je externe repository. Controleer vóór het pushen wat de commit bevat: sleutels, wachtwoorden en echte gebruikersgegevens mogen er niet in staan. Als je niet weet welke wijzigingen je moet opslaan, vraag Codex dan eerst om ze op te sommen en het doel ervan uit te leggen, zonder bestanden te verwijderen of naar de repository te pushen. | Onderdeel van het project | Wat je vóór de overdracht controleert | |----|----| | Bronbestanden en Git-geschiedenis | De noodzakelijke wijzigingen zijn opgeslagen en beschikbaar op de geselecteerde branch van de externe repository | | README en agentinstructies | Opstartstappen, controles en beperkingen zijn gedocumenteerd; de instructies zijn actueel | | Afhankelijkheidsbestanden | De afhankelijkheidsdefinities en het lockbestand dat het project gebruikt — het bestand dat versies vastlegt — zijn opgeslagen | | Geheimen | Er is een aparte, veilige manier om ze op de server in te stellen; de waarden staan niet in Git en worden niet via chat verstuurd | | Database en geüploade bestanden | Je weet waar je toegestane testgegevens kunt ophalen en hoe je die volgens de projectinstructies herstelt | Ga er niet van uit dat het klonen van de repository een externe database, de inhoud van een genegeerde map of je gesprekken met Codex overzet. Chatgeschiedenis, abonnementen, profielen en de eigen instellingen van agents maken geen deel uit van deze overdrachtsmethode. ## De juiste branch naar de server kopiëren Sla eerst op de broncomputer de uitvoer van dit commando op: ```bash git status --porcelain=v2 --branch ``` De regel `# branch.oid` toont de huidige commit en `# branch.head` de branch. Een commit is een opgeslagen versie van het project. Bij een gebruikelijk project met bestaande commits kun je hiermee de bronkopie en de nieuwe kopie vergelijken; deze vergelijking controleert geen niet-gecommitte wijzigingen. Ga op de server naar de map waarin je je projecten bewaart. Kloon je repository naar een nieuwe map. Vervang in het onderstaande sjabloon `REPOSITORY_URL` door de URL van je repository, `BRANCH_NAME` door de naam van de branch die je hebt opgeslagen en gepusht, en `my-project` door de naam die je voor de nieuwe map wilt gebruiken: ```bash git clone --branch BRANCH_NAME REPOSITORY_URL my-project cd my-project git status --porcelain=v2 --branch ``` Dit is een sjabloon, geen kant-en-klare URL om te kopiëren. Met `git clone` maak je een map en een werkkopie van de geselecteerde branch. Als de doelmap al bestaat, moet deze leeg zijn: verwijder de inhoud niet om het commando opnieuw uit te voeren, maar kies een nieuwe naam. Vergelijk `# branch.oid` in beide kopieën. Als de waarden verschillen, begin dan niet met code repareren op de server: controleer de geselecteerde branch, de commits die je hebt gepusht en of er parallelle wijzigingen zijn gemaakt. Als de statusuitvoer gewijzigde bestanden toont, onderzoek die dan afzonderlijk. Gebruik geen opschoning of geforceerde reset om ze “gelijk te maken”. Voor repositories met Git-submodules — geneste repositories — moet je ook hun inhoud ophalen. `git clone` heeft hiervoor de optie `--recurse-submodules`; gebruik die als het project daadwerkelijk submodules bevat en de URL's ervan zijn gecontroleerd. Projecten met andere externe bronnen kunnen een aanvullende procedure vereisen die in de README wordt beschreven. ## Afhankelijkheden herstellen volgens de projectregels Lees eerst de README en de configuratiebestanden van het project. Zoek uit welke runtimeversie vereist is en welke pakketbeheerder wordt gebruikt om afhankelijkheden te installeren. Vervang het gebruikelijke hulpmiddel van het project niet door npm alleen omdat npm in het voorbeeld hieronder staat. **Een hypothetisch voorbeeld voor Node.js en npm:** de repository bevat consistente bestanden `package.json` en `package-lock.json`, en op de server is een geschikte versie van Node.js geïnstalleerd. Voer in dat geval dit uit in de projectmap: ```bash npm ci ``` Volgens de [documentatie van npm ci](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md) installeert het commando de afhankelijkheden voor het hele project vanuit het lockbestand zonder `package.json` of `package-lock.json` te herschrijven. Als de inhoud daarvan niet overeenkomt, mislukt de installatie. Een eventuele bestaande map `node_modules` wordt vóór de installatie verwijderd. Als het lockbestand is gemaakt met opties die van invloed zijn op de afhankelijkheidsboom, zoals `--legacy-peer-deps`, heeft `npm ci` dezelfde opties nodig. Controleer de instructies en instellingen van het bronproject. Verwijder het lockbestand niet en werk niet alle afhankelijkheden bij om de eerste overdrachtsfout te verbergen. Controleer vóór de installatie de installatie- en opstartcommando's van je eigen project. Voer ze uit in een aparte werkkopie zonder toegang tot productiegegevens en stel eventuele benodigde omgevingswaarden buiten chat en Git in. Gebruik waar mogelijk testgegevens met beperkte rechten om het project te controleren. Als het project afhankelijk is van een database of bestanden, herstel dan eerst een toegestane testdataset volgens de instructies; identieke bronbestanden vervangen die gegevens niet. Voer na de installatie de bestaande controles uit de README uit: tests en een build, als die zijn opgegeven. De namen van de commando's hangen af van het project. Dat de afhankelijkheden succesvol zijn geïnstalleerd, betekent nog niet dat de applicatie werkt. ## De werkkopie openen in Hermes Ga in de serverterminal naar de hoofdmap van de nieuwe kopie en start de agent die al is geïnstalleerd: ```bash cd /absolute/path/to/my-project hermes ``` `/absolute/path/to/my-project` is hier een tijdelijke aanduiding voor het volledige pad naar je project. Controleer op het opstartscherm van Hermes de werkmap en de omgeving waarin terminalcommando's worden uitgevoerd. Deze opstartmethode is bedoeld voor Hermes' lokale terminalomgeving op de server. Als SSH of Docker is ingesteld, kan de agent commando's in een andere omgeving uitvoeren; bevestig eerst dat het projectpad daar beschikbaar is. Vraag de agent om met zijn terminaltool de daadwerkelijke werkmap te bevestigen en lees daarna de README en de projectinstructies. Beschouw een mapnaam in een bericht niet als voldoende verificatie. De onderstaande volgorde staat in een vastgezette versie van de documentatie en kan afwijken van de versie van Hermes die je hebt geïnstalleerd. Controleer de actuele instructies in je sessie. Hermes ondersteunt `AGENTS.md`, maar of het dat bestand leest, hangt af van de prioriteit van contextbestanden. Volgens de [officiële Hermes-documentatie](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md) wordt één type instructiebestand geselecteerd: eerst `.hermes.md`, daarna `AGENTS.override.md`, `AGENTS.md`, `CLAUDE.md` en `.cursorrules`. Controleer vóór je begint of er een oude `.hermes.md` of een persoonlijke `AGENTS.override.md` is: ga er niet van uit dat de agent noodzakelijkerwijs ook de `AGENTS.md` ernaast toepast. Behoud in de geselecteerde instructies het doel van het project, de controlecommando's en de beperkingen op wijzigingen. Maak er geen archief van gesprekken van. Als je ook de instellingen van de agents moet overzetten, is dat een ander proces; de reikwijdte ervan wordt uitgelegd in de [handleiding voor migratie van Claude Code naar Codex](https://ailoot.ai/blog/nl/migrate-claude-code-to-codex/). ## Geef de agent één taak en controleer het resultaat Begin met het project te lezen zonder wijzigingen aan te brengen. Bijvoorbeeld: ``` We werken met een bestaand project in de map die ik heb opgegeven. Bevestig de daadwerkelijke werkmap met de terminaltool. Lees de README en de huidige projectinstructies. Open geen bestanden met geheimen en geef geen omgevingswaarden weer. Geef de controlecommando's en de vereisten om ze uit te voeren weer. Wijzig of installeer voorlopig niets en push niets naar de repository. ``` Spreek daarna één kleine taak af, zoals het corrigeren van tekst in de interface. Geef aan welke bestanden of welk gebied mag worden gewijzigd en verbied onbedoelde updates van afhankelijkheden. Als je het experiment van de hoofdkopie wilt scheiden, lees dan eerst over een [aparte Git-worktree-werkkopie](https://ailoot.ai/blog/nl/codex-worktree-separate-task/). Accepteer het resultaat op basis van de bestandswijzigingen en herhaalde projectcontroles. Sla vóór een mogelijk mislukte proef de bronkopie en een herstelpunt op; vraag de agent niet om alle wijzigingen in één keer terug te zetten. Vergelijk de fout bij een mislukte controle met de bronkopie: zo kun je een overdrachtsprobleem onderscheiden van een defect dat er al was. De overdracht is voltooid wanneer de vereiste versie van de bronbestanden aanwezig is, de omgeving is hersteld, de noodzakelijke gegevens beschikbaar zijn in een veilige testomgeving, de controles slagen en Hermes in precies deze map werkt. De applicatie beschikbaar maken voor bezoekers is een aparte volgende fase en maakt geen deel uit van deze controle. Maak kennis met [Ailoot](https://ailoot.ai/). ## Vragen en antwoorden ### Verplaatst het klonen van de repository de hele werkomgeving? Nee. Git klonen neemt geen genegeerde bestanden, externe databases, geüploade gegevens, geheimen of agentchatgeschiedenis mee. Herstel benodigde afhankelijkheden en toegestane testgegevens afzonderlijk volgens de projectinstructies. ### Wat vergelijk ik voordat ik de serverkopie bewerk? Vergelijk de opgeslagen branch en commitidentificatie met de bronkopie, bekijk ongecommitte wijzigingen en laat Hermes de werkelijke werkmap controleren. Voer daarna de bestaande projectcontroles uit in precies die kopie. ## Ailoot · Het bedrijf en zijn projectenportefeuille Ailoot bouwt op opgebouwde operationele ervaring, een groot klantenbestand, een stabiele dienst en doorlopende KPI-controle. Het bedrijf en zijn projectenportefeuille: miljoenen klanten; maandelijkse verkopen in de miljarden. Ailoot gebruikt die operationele ervaring voor API-toegang tot AI-functies in klantproducten, agents, applicaties en automatiseringen.