Przenoszenie projektu z Codex do Hermes na serwerze

Aby dowiedzieć się, jak korzystać z usługi, zobacz dokumentację Ailoot.

Co przygotować przed przeniesieniem#

Repozytorium to folder projektu wraz z historią zmian Git. Kopia robocza zawiera pliki, które edytujesz. Celem jest umieszczenie tej kopii na serwerze i kontynuowanie pracy nad projektem. Nie musisz jeszcze udostępniać aplikacji odwiedzającym.

Jeśli agent nie jest jeszcze zainstalowany na serwerze, zacznij od instalacji Hermes Agent na VPS. Potrzebne będą działająca instalacja Hermes, terminal serwera i Git. Potrzebujesz też zdalnego repozytorium dostępnego z serwera. Jeśli jeszcze go nie masz, najpierw je utwórz i zapisz w nim projekt bez sekretów. W przypadku prywatnego repozytorium wcześniej skonfiguruj odczyt z własnego konta; nie umieszczaj tokenu w adresie URL repozytorium ani w wiadomości do agenta.

Na czas przenoszenia wstrzymaj równoległe edycje projektu. Na komputerze źródłowym otwórz terminal bezpośrednio w folderze projektu i uruchom:

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

Pierwsze polecenie pokazuje gałąź i stan plików. M oznacza modyfikację, a ?? — plik, którego Git jeszcze nie śledzi. W drugim poleceniu ignorowane pliki są oznaczone jako !!. Zwykły czysty status nie dowodzi, że poza Gitem nie ma potrzebnych plików.

Zapisz potrzebne zmiany w osobnym commicie i wypchnij właściwą gałąź do zdalnego repozytorium w zwykły dla siebie sposób. Przed wypchnięciem sprawdź zawartość commita: nie mogą się w nim znaleźć klucze, hasła ani prawdziwe dane użytkowników. Jeśli nie wiesz, które zmiany zapisać, poproś najpierw Codex o ich wylistowanie i wyjaśnienie ich celu, bez usuwania plików ani wypychania zmian do repozytorium.

Nie zakładaj, że sklonowanie repozytorium przeniesie zewnętrzną bazę danych, zawartość ignorowanego folderu ani rozmowy z Codex. Historia czatu, subskrypcje, profile i własne ustawienia agentów nie należą do zakresu tej metody przenoszenia.

Skopiuj właściwą gałąź na serwer#

Najpierw zapisz wynik tego polecenia na komputerze źródłowym:

git status --porcelain=v2 --branch

Wiersz # branch.oid pokazuje bieżący commit, a # branch.head — gałąź. Commit to zapisana wersja projektu. W przypadku typowego projektu z istniejącymi commitami pozwala to porównać kopię źródłową z nową kopią; porównanie nie sprawdza zmian, które nie zostały zatwierdzone.

Na serwerze przejdź do katalogu, w którym będziesz przechowywać projekty. Sklonuj repozytorium do nowego folderu. W poniższym szablonie zastąp REPOSITORY_URL adresem URL repozytorium, BRANCH_NAME nazwą zapisanej i wypchniętej gałęzi, a my-project nazwą, którą chcesz nadać nowemu folderowi:

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

To szablon, a nie gotowy adres URL do skopiowania. git clone tworzy folder i kopię roboczą wybranej gałęzi. Jeśli folder docelowy już istnieje, musi być pusty. Nie usuwaj jego zawartości, aby ponownie wykonać polecenie; wybierz nową nazwę.

Porównaj # branch.oid w obu kopiach. Jeśli wartości się różnią, nie zaczynaj naprawiać kodu na serwerze: sprawdź wybraną gałąź, wypchnięte commity i to, czy wprowadzono równoległe zmiany. Jeśli wynik statusu pokazuje zmodyfikowane pliki, zbadaj je osobno. Nie używaj czyszczenia ani wymuszonego resetu, aby „je dopasować”.

Repozytoria zawierające podmoduły Git — zagnieżdżone repozytoria — wymagają również pobrania ich zawartości. git clone ma w tym celu opcję --recurse-submodules; użyj jej, jeśli projekt rzeczywiście zawiera podmoduły i ich adresy URL zostały sprawdzone. Projekty zależne od innych zasobów zewnętrznych mogą wymagać dodatkowej procedury opisanej w README.

Odtwórz zależności zgodnie z zasadami projektu#

Najpierw przeczytaj README i pliki konfiguracyjne projektu. Ustal, jaka wersja środowiska uruchomieniowego jest wymagana i jakiego menedżera pakietów używa się do instalowania zależności. Nie zastępuj zwykłego narzędzia projektu npm tylko dlatego, że pojawia się w poniższym przykładzie.

Hipotetyczny przykład dla Node.js i npm: repozytorium zawiera spójne pliki package.json i package-lock.json, a na serwerze jest zainstalowana wersja Node.js odpowiednia dla projektu. W takim przypadku uruchom to polecenie w folderze projektu:

npm ci

Zgodnie z dokumentacją npm ci polecenie instaluje zależności całego projektu z pliku blokady, nie przepisując package.json ani package-lock.json. Jeśli zawartość tych plików jest niespójna, instalacja kończy się niepowodzeniem. Przed instalacją usuwany jest każdy istniejący folder node_modules.

Jeśli plik blokady został utworzony z opcjami wpływającymi na drzewo zależności, takimi jak --legacy-peer-deps, npm ci wymaga użycia tych samych opcji. Sprawdź instrukcje i ustawienia projektu źródłowego. Nie usuwaj pliku blokady ani nie aktualizuj wszystkich zależności, aby ukryć pierwszy błąd przenoszenia.

Przed instalacją sprawdź polecenia instalacji i uruchamiania używane w Twoim projekcie. Uruchom je w osobnej kopii roboczej bez dostępu do danych produkcyjnych, a wymagane wartości środowiskowe ustaw poza czatem i Gitem. Jeśli to możliwe, sprawdź projekt przy użyciu poświadczeń testowych o ograniczonych uprawnieniach. Jeśli projekt zależy od bazy danych lub plików, najpierw odtwórz dozwolony testowy zestaw danych zgodnie z instrukcjami; identyczne pliki źródłowe nie zastępują tych danych.

Po instalacji uruchom istniejące kontrole opisane w README: testy i kompilację, jeśli są dostępne. Nazwy poleceń zależą od projektu. Pomyślne zainstalowanie zależności nie oznacza jeszcze, że aplikacja działa.

Otwórz kopię roboczą w Hermes#

W terminalu serwera przejdź do katalogu głównego nowej kopii i uruchom już zainstalowanego agenta:

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

/absolute/path/to/my-project to symbol zastępczy pełnej ścieżki do projektu. Na ekranie uruchamiania Hermes sprawdź katalog roboczy i środowisko, w którym wykonywane są polecenia terminala. Ta metoda uruchamiania dotyczy lokalnego środowiska terminala Hermes na serwerze. Jeśli skonfigurowano SSH lub Docker, agent może wykonywać polecenia w innym środowisku; najpierw potwierdź dostępną tam ścieżkę do projektu.

Poproś agenta, aby za pomocą narzędzia terminala potwierdził rzeczywisty folder roboczy, a następnie przeczytał README i instrukcje projektu. Sama nazwa folderu podana w wiadomości nie wystarczy do weryfikacji.

Poniższa kolejność jest podana w przypiętej wersji dokumentacji i może różnić się od tej w zainstalowanej wersji Hermes. Sprawdź aktualne instrukcje w swojej sesji. Hermes obsługuje AGENTS.md, ale to, czy odczyta ten plik, zależy od priorytetów plików kontekstowych. Zgodnie z oficjalną dokumentacją Hermes wybierany jest jeden rodzaj pliku z instrukcjami, w następującej kolejności: .hermes.md, AGENTS.override.md, AGENTS.md, CLAUDE.md i .cursorrules. Przed rozpoczęciem pracy sprawdź, czy istnieje stary plik .hermes.md lub osobisty plik AGENTS.override.md; nie zakładaj, że agent na pewno zastosuje również znajdujący się obok nich plik AGENTS.md.

W wybranych instrukcjach zachowaj cel projektu, polecenia kontrolne i ograniczenia dotyczące zmian. Nie przekształcaj ich w archiwum rozmów. Jeśli chcesz przenieść również same ustawienia agentów, jest to osobna procedura; jej zakres opisano w poradniku migracji z Claude Code do Codex.

Przydziel agentowi jedno zadanie i sprawdź wynik#

Na początek zapoznaj się z projektem, nie wprowadzając zmian. Możesz na przykład napisać:

Pracujemy nad istniejącym projektem w folderze, który wskazałem.
Potwierdź rzeczywisty katalog roboczy za pomocą narzędzia terminala.
Przeczytaj README i aktualne instrukcje projektu.
Nie otwieraj plików zawierających sekrety ani nie wyświetlaj wartości zmiennych środowiskowych.
Wymień polecenia kontrolne i warunki wstępne ich uruchomienia.
Na razie niczego nie zmieniaj ani nie instaluj i nie wysyłaj zmian do repozytorium.

Następnie uzgodnij jedno niewielkie zadanie, na przykład poprawienie tekstu w interfejsie. Określ pliki lub obszar do zmiany i zabroń przypadkowych aktualizacji zależności. Jeśli chcesz oddzielić eksperyment od głównej kopii, najpierw zapoznaj się z osobną kopią roboczą Git worktree.

Zaakceptuj wynik na podstawie zmian w plikach i ponownego wykonania kontroli projektu. Przed eksperymentem, który może się nie powieść, zapisz kopię źródłową i punkt przywracania; nie proś agenta o zbiorcze cofnięcie wszystkich zmian. Jeśli kontrola się nie powiedzie, porównaj błąd z kopią źródłową: pomoże to odróżnić problem z przeniesieniem od usterki, która już wcześniej występowała.

Przenoszenie można uznać za zakończone, gdy wymagana wersja plików źródłowych znajduje się na miejscu, środowisko zostało odtworzone, potrzebne dane są dostępne w bezpiecznym środowisku testowym, kontrole przechodzą pomyślnie, a Hermes działa dokładnie w tym folderze. Publikowanie aplikacji dla odwiedzających to osobny, następny etap i nie wchodzi w zakres tej kontroli.

Poznaj Ailoot.