# Przenoszenie projektu z Codex do Hermes na serwerze > Przenoszenie repozytorium na serwer, aby kontynuować pracę w Hermes: zapisane zmiany, zależności, sekrety, folder roboczy i kontrole przed dalszym rozwojem. Source: https://ailoot.ai/blog/pl/codex-project-to-hermes-server/ Canonical: https://ailoot.ai/blog/pl/codex-project-to-hermes-server/ Language: pl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-082 Revision: sha256-9266d70877cffa045e951fa260c0819662ad21d56583c0afb60ae0856e78d857 Aby dowiedzieć się, jak korzystać z usługi, zobacz [dokumentację Ailoot](https://ailoot.ai/docs/).
Najważniejsze informacje Aby kontynuować pracę w Hermes nad projektem utworzonym w Codex, przenieś samo repozytorium i odtwórz jego środowisko. W tym podejściu nie musisz wykonywać osobnego kroku „importowania projektu z agenta”. Najpierw sprawdź zapisane pliki i zależności, a potem otwórz właściwy folder w Hermes. Ten poradnik zakłada, że serwer i Hermes są już skonfigurowane oraz że masz dostęp do repozytorium.
## 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](https://ailoot.ai/blog/pl/hermes-agent-vps-24-7/). 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: ```bash 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. | Część projektu | Co sprawdzić przed przeniesieniem | |----|----| | Pliki źródłowe i historia Git | Potrzebne zmiany są zapisane i dostępne w wybranej gałęzi zdalnego repozytorium | | README i instrukcje dla agentów | Udokumentowano kroki uruchamiania, kontrole i ograniczenia; instrukcje są aktualne | | Pliki zależności | Zapisano definicje zależności i używany w projekcie plik blokady, który przypina wersje | | Sekrety | Istnieje osobny, bezpieczny sposób ustawienia ich na serwerze; ich wartości nie ma w Gicie ani w czacie | | Baza danych i przesłane pliki | Wiesz, skąd pobrać dozwolone dane testowe i jak je odtworzyć zgodnie z instrukcjami projektu | 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: ```bash 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: ```bash 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: ```bash npm ci ``` Zgodnie z [dokumentacją npm ci](https://raw.githubusercontent.com/npm/cli/c039090578a5b21a1aa3aba9c96e199feaf1823a/docs/lib/content/commands/npm-ci.md) 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: ```bash 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](https://raw.githubusercontent.com/NousResearch/hermes-agent/44f6d3bbeee093ab985bb1e16d7346fdc3b1db7a/website/docs/user-guide/features/context-files.md) 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](https://ailoot.ai/blog/pl/migrate-claude-code-to-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](https://ailoot.ai/blog/pl/codex-worktree-separate-task/). 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](https://ailoot.ai/). ## Pytania i odpowiedzi ### Czy klonowanie repozytorium przenosi całe środowisko robocze? Nie. Git nie przenosi ignorowanych plików, zewnętrznych baz, przesłanych danych, sekretów ani historii czatu agenta. Wymagane zależności i dozwolone dane testowe odtwórz osobno według instrukcji projektu. ### Co porównać przed edycją kopii na serwerze? Porównaj zapisaną gałąź i identyfikator commita ze źródłem, obejrzyj niezacommitowane zmiany i poproś Hermes o sprawdzenie faktycznego katalogu roboczego. Potem uruchom istniejące sprawdzenia projektu w tej dokładnej kopii. ## Ailoot · Firma i jej portfel projektów Ailoot opiera się na zgromadzonym doświadczeniu operacyjnym, szerokiej bazie klientów, stabilnej usłudze i stałej kontroli KPI. Firma i jej portfel projektów: miliony klientów; miesięczna sprzedaż liczona w miliardach. Ailoot wykorzystuje to doświadczenie operacyjne, zapewniając dostęp przez API do funkcji AI w produktach klientów, agentach, aplikacjach i automatyzacjach.