Ein Projekt von Codex zu Hermes auf einem Server übertragen

Hilfe zur Nutzung des Dienstes findest du in der Ailoot-Dokumentation.

Was du vor der Übertragung vorbereiten solltest#

Ein Repository ist ein Projektordner mit seiner Git-Änderungshistorie. Eine Arbeitskopie enthält die Dateien, die du bearbeitest. Hier geht es darum, diese Kopie auf den Server zu übertragen und die Entwicklung fortzusetzen. Die Anwendung muss dafür noch nicht für Besucher verfügbar sein.

Wenn der Agent noch nicht auf dem Server installiert ist, beginne mit der Installation von Hermes Agent auf einem VPS. Hier benötigst du eine funktionierende Hermes-Installation, das Serverterminal und Git. Du brauchst ein Remote-Repository, auf das vom Server aus zugegriffen werden kann. Falls du noch keines hast, erstelle zuerst eines und speichere das Projekt dort ohne Geheimnisse. Richte für ein privates Repository den Lesezugriff über dein eigenes Konto im Voraus ein. Füge ein Token weder in die Repository-URL noch in eine Nachricht an den Agenten ein.

Pausiere parallele Änderungen am Projekt während der Übertragung. Öffne auf dem Quellcomputer ein Terminal direkt im Projektordner und führe Folgendes aus:

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

Der erste Befehl zeigt den Branch und den Status der Dateien an. M steht für eine Änderung und ?? für eine Datei, die Git noch nicht verfolgt. Im zweiten Befehl sind ignorierte Dateien mit !! markiert. Ein normaler sauberer Status beweist nicht, dass es außerhalb von Git keine notwendigen Dateien gibt.

Speichere die erforderlichen Änderungen in einem separaten Commit und pushe den richtigen Branch wie gewohnt in dein Remote-Repository. Prüfe vor dem Push, was der Commit enthält: Schlüssel, Passwörter und echte Nutzerdaten dürfen nicht enthalten sein. Wenn du nicht weißt, welche Änderungen gespeichert werden sollen, bitte Codex zuerst, sie aufzulisten und ihren Zweck zu erklären, ohne Dateien zu löschen oder etwas ins Repository zu pushen.

Gehe nicht davon aus, dass das Klonen des Repositorys eine externe Datenbank, den Inhalt eines ignorierten Ordners oder deine Gespräche mit Codex überträgt. Chatverlauf, Abonnements, Profile und eigene Einstellungen der Agenten gehören nicht zu dieser Übertragungsmethode.

Den richtigen Branch auf den Server kopieren#

Speichere zuerst auf dem Quellcomputer die Ausgabe dieses Befehls:

git status --porcelain=v2 --branch

Die Zeile # branch.oid zeigt den aktuellen Commit, und # branch.head zeigt den Branch. Ein Commit ist eine gespeicherte Version des Projekts. Bei einem typischen Projekt mit bestehenden Commits kannst du damit die Quellkopie und die neue Kopie vergleichen. Dieser Vergleich prüft keine nicht gespeicherten Änderungen.

Wechsle auf dem Server in das Verzeichnis, in dem du deine Projekte ablegst. Klone dein Repository in einen neuen Ordner. Ersetze in der Vorlage unten REPOSITORY_URL durch die URL deines Repositorys, BRANCH_NAME durch den Namen des Branches, den du gespeichert und gepusht hast, und my-project durch den gewünschten Namen des neuen Ordners:

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

Dies ist eine Vorlage und keine fertige URL zum Kopieren. git clone erstellt einen Ordner und eine Arbeitskopie des ausgewählten Branches. Wenn der Zielordner bereits existiert, muss er leer sein. Lösche seinen Inhalt nicht, um den Befehl erneut auszuführen, sondern wähle einen neuen Namen.

Vergleiche # branch.oid in beiden Kopien. Wenn die Werte unterschiedlich sind, beginne nicht damit, Code auf dem Server zu korrigieren. Prüfe den ausgewählten Branch, die Commits, die du gepusht hast, und ob parallel Änderungen vorgenommen wurden. Wenn die Statusausgabe geänderte Dateien zeigt, untersuche sie separat. Verwende kein Aufräumen und keinen erzwungenen Reset, um die Kopien „anzugleichen“.

Repositories mit Git-Submodulen – verschachtelten Repositorys – erfordern auch das Abrufen ihrer Inhalte. git clone bietet dafür die Option --recurse-submodules. Verwende sie, wenn das Projekt tatsächlich Submodule enthält und deren URLs geprüft wurden. Für Projekte mit anderen externen Ressourcen kann ein zusätzliches Verfahren erforderlich sein, das in der README beschrieben ist.

Abhängigkeiten gemäß den Projektvorgaben wiederherstellen#

Lies zuerst die README und die Projektkonfigurationsdateien. Finde heraus, welche Runtime-Version erforderlich ist und welcher Paketmanager zum Installieren der Abhängigkeiten verwendet wird. Ersetze das übliche Werkzeug des Projekts nicht einfach durch npm, nur weil es im folgenden Beispiel vorkommt.

Ein hypothetisches Beispiel für Node.js und npm: Das Repository enthält zueinander passende Dateien package.json und package-lock.json, und auf dem Server ist eine für das Projekt geeignete Node.js-Version installiert. Führe in diesem Fall im Projektordner Folgendes aus:

npm ci

Laut der Dokumentation zu npm ci installiert der Befehl die Abhängigkeiten für das gesamte Projekt anhand der Lockdatei, ohne package.json oder package-lock.json neu zu schreiben. Wenn ihr Inhalt nicht übereinstimmt, schlägt die Installation fehl. Ein vorhandener Ordner node_modules wird vor der Installation gelöscht.

Wenn die Lockdatei mit Optionen erstellt wurde, die sich auf den Abhängigkeitsbaum auswirken, etwa --legacy-peer-deps, benötigt npm ci dieselben Optionen. Prüfe die Anweisungen und Einstellungen des Quellprojekts. Lösche nicht die Lockdatei und aktualisiere nicht alle Abhängigkeiten, um den ersten Übertragungsfehler zu verbergen.

Prüfe vor der Installation die Installations- und Startbefehle deines Projekts. Führe sie in einer separaten Arbeitskopie ohne Zugriff auf Produktionsdaten aus und richte erforderliche Umgebungswerte außerhalb des Chats und von Git ein. Verwende nach Möglichkeit Testzugangsdaten mit eingeschränkten Berechtigungen, um das Projekt zu prüfen. Wenn das Projekt von einer Datenbank oder Dateien abhängt, stelle zuerst einen zulässigen Testdatensatz gemäß den Projektanweisungen wieder her. Identische Quelldateien ersetzen diese Daten nicht.

Führe nach der Installation die vorhandenen Prüfungen aus der README aus: Tests und einen Build, falls vorgesehen. Die Befehlsnamen hängen vom Projekt ab. Eine erfolgreiche Installation der Abhängigkeiten bedeutet noch nicht, dass die Anwendung funktioniert.

Die Arbeitskopie in Hermes öffnen#

Wechsle im Serverterminal zum Stammverzeichnis der neuen Kopie und starte den bereits installierten Agenten:

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

/absolute/path/to/my-project ist hier ein Platzhalter für den vollständigen Pfad zu deinem Projekt. Prüfe auf dem Hermes-Startbildschirm das Arbeitsverzeichnis und die Umgebung, in der Terminalbefehle ausgeführt werden. Diese Startmethode ist für Hermes' lokale Terminalumgebung auf dem Server gedacht. Wenn SSH oder Docker konfiguriert ist, kann der Agent Befehle in einer anderen Umgebung ausführen. Bestätige zuerst, dass der Projektpfad dort verfügbar ist.

Bitte den Agenten, sein tatsächliches Arbeitsverzeichnis mit seinem Terminal-Tool zu bestätigen, und lies anschließend die README und die Projektanweisungen. Ein Ordnername in einer Nachricht reicht nicht als Bestätigung aus.

Die folgende Reihenfolge ist in einer festgelegten Version der Dokumentation angegeben und kann von der Reihenfolge in deiner installierten Hermes-Version abweichen. Prüfe die aktuellen Anweisungen in deiner Sitzung. Hermes unterstützt AGENTS.md, aber ob die Datei gelesen wird, hängt von der Priorität der Kontextdateien ab. Laut der offiziellen Hermes-Dokumentation wird eine Art von Anweisungsdatei ausgewählt: .hermes.md, dann AGENTS.override.md, AGENTS.md, CLAUDE.md und .cursorrules. Prüfe vor Arbeitsbeginn, ob eine alte .hermes.md oder eine persönliche AGENTS.override.md vorhanden ist. Gehe nicht davon aus, dass der Agent zwangsläufig die danebenliegende AGENTS.md anwendet.

Behalte in den ausgewählten Anweisungen den Projektzweck, die Prüfungsbefehle und die Einschränkungen für Änderungen bei. Verwandle sie nicht in ein Archiv von Gesprächen. Wenn du auch die Einstellungen der Agenten übertragen musst, ist das ein anderer Prozess. Sein Umfang wird in der Anleitung zur Migration von Claude Code zu Codex erklärt.

Dem Agenten eine Aufgabe geben und das Ergebnis prüfen#

Lass dir zuerst das Projekt zeigen, ohne Änderungen vorzunehmen. Zum Beispiel:

Wir arbeiten mit einem bestehenden Projekt in dem von mir angegebenen Ordner.
Bestätige das tatsächliche Arbeitsverzeichnis mit dem Terminal-Tool.
Lies die README-Datei und die aktuellen Projektanweisungen.
Öffne keine Dateien mit Geheimnissen und gib keine Umgebungswerte aus.
Liste die Prüfungsbefehle und die Voraussetzungen für ihre Ausführung auf.
Ändere oder installiere vorerst nichts und pushe nichts ins Repository.

Vereinbare danach eine kleine Aufgabe, zum Beispiel eine Textkorrektur in der Benutzeroberfläche. Gib an, welche Dateien oder Bereiche geändert werden dürfen, und untersage beiläufige Aktualisierungen von Abhängigkeiten. Wenn du das Experiment von der Hauptkopie trennen möchtest, informiere dich zuerst über eine separate Git-Arbeitskopie mit Worktree.

Nimm das Ergebnis anhand der Dateiänderungen und der erneut ausgeführten Projektprüfungen ab. Speichere vor einem möglicherweise scheiternden Experiment die Quellkopie und einen Wiederherstellungspunkt. Bitte den Agenten nicht, pauschal alle Änderungen zurückzusetzen. Wenn eine Prüfung fehlschlägt, vergleiche den Fehler mit der Quellkopie. So lässt sich unterscheiden, ob ein Übertragungsproblem vorliegt oder ein bereits zuvor vorhandener Fehler.

Die Übertragung gilt als abgeschlossen, wenn die benötigte Version der Quelldateien vorhanden ist, die Umgebung wiederhergestellt wurde, die erforderlichen Daten in einer sicheren Testumgebung verfügbar sind, die Prüfungen erfolgreich sind und Hermes in genau diesem Ordner arbeitet. Die Veröffentlichung der Anwendung für Besucher ist ein separater nächster Schritt und nicht Teil dieser Prüfung.

Lerne Ailoot kennen.