Loyihani Codex’dan Hermes’ga serverda ko‘chirish

Xizmatdan foydalanish bo‘yicha yordam uchun Ailoot hujjatlariga qarang.

Ko‘chirishdan oldin nimalarni tayyorlash kerak#

Repozitoriy — Git o‘zgarishlar tarixiga ega loyiha papkasi. Ishchi nusxa — siz tahrirlaydigan fayllarni o‘z ichiga oladi. Bu yerdagi vazifa shu nusxani serverga olib o‘tish va ishlab chiqishni davom ettirishdir. Hozircha ilovani tashrif buyuruvchilar uchun ochishingiz shart emas.

Agar agent serverda hali o‘rnatilmagan bo‘lsa, Hermes Agent’ni VPS’ga o‘rnatish qo‘llanmasidan boshlang. Bu yerda sizga ishlaydigan Hermes o‘rnatmasi, server terminali va Git kerak bo‘ladi. Serverdan foydalanish mumkin bo‘lgan masofaviy repozitoriy ham zarur; agar hali bo‘lmasa, avval uni yarating va loyihani maxfiy ma’lumotlarsiz o‘sha yerda saqlang. Xususiy repozitoriy uchun oldindan o‘z hisobingizdan o‘qish ruxsatini sozlang; tokenni repozitoriy URL manziliga yoki agentga yuboriladigan xabarga qo‘ymang.

Ko‘chirish paytida loyihaga parallel o‘zgartirishlar kiritishni to‘xtatib turing. Manba kompyuterda loyiha papkasining o‘zida terminalni oching va quyidagilarni bajaring:

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

Birinchi buyruq tarmoq va fayllar holatini ko‘rsatadi. M o‘zgartirilgan faylni, ?? esa Git hali kuzatmayotgan faylni anglatadi. Ikkinchi buyruqda e’tiborsiz qoldirilgan fayllar !! bilan belgilanadi. Oddiy, toza holat Git’dan tashqarida zarur fayllaringiz yo‘qligini isbotlamaydi.

Kerakli o‘zgarishlarni alohida commit’da saqlang va odatdagi usulingiz bilan to‘g‘ri tarmoqni masofaviy repozitoriyga push qiling. Push qilishdan oldin commit ichidagilarni tekshiring: kalitlar, parollar va haqiqiy foydalanuvchi ma’lumotlari kiritilmasligi kerak. Qaysi o‘zgarishlarni saqlashni bilmasangiz, avval Codex’dan ularni sanab berib, maqsadini tushuntirishni so‘rang; fayllarni o‘chirish yoki repozitoriyga push qilishga ruxsat bermang.

Repozitoriyni klonlash tashqi ma’lumotlar bazasini, e’tiborsiz qoldirilgan papka tarkibini yoki Codex bilan suhbatlaringizni ko‘chiradi deb o‘ylamang. Chat tarixi, obunalar, profillar va agentlarning o‘z sozlamalari bu ko‘chirish usuliga kirmaydi.

To‘g‘ri tarmoqni serverga ko‘chirish#

Avval manba kompyuterda quyidagi buyruq natijasini saqlang:

git status --porcelain=v2 --branch

# branch.oid qatorida joriy commit, # branch.head qatorida esa tarmoq ko‘rsatiladi. Commit — loyihaning saqlangan versiyasi. Oldindan commit’lari bor odatiy loyihada bu manba va yangi nusxalarni solishtirish imkonini beradi; solishtirish commit qilinmagan o‘zgarishlarni tekshirmaydi.

Serverda loyihalaringizni saqlaydigan katalogga o‘ting. Repozitoriyni yangi papkaga klonlang. Quyidagi namunada REPOSITORY_URL o‘rniga repozitoriy URL manzilini, BRANCH_NAME o‘rniga saqlab push qilgan tarmoq nomini, my-project o‘rniga esa yangi papkaga bermoqchi bo‘lgan nomingizni yozing:

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

Bu tayyor nusxa ko‘chirib ishlatadigan URL emas, balki namuna. git clone papka va tanlangan tarmoqning ishchi nusxasini yaratadi. Manzil papkasi allaqachon mavjud bo‘lsa, u bo‘sh bo‘lishi kerak: buyruqni qayta bajarish uchun uning ichidagi narsalarni o‘chirmang, yangi nom tanlang.

Ikkala nusxadagi # branch.oid qiymatlarini solishtiring. Qiymatlar farq qilsa, serverda kodni tuzatishni boshlamang: tanlangan tarmoqni, push qilgan commit’laringizni va parallel o‘zgarishlar kiritilgan-kiritilmaganini tekshiring. Holat natijasida o‘zgartirilgan fayllar ko‘rsatilsa, ularni alohida tekshiring. Qiymatlarni “moslashtirish” uchun tozalash yoki majburiy resetdan foydalanmang.

Git submodullari — ichma-ich repozitoriylari — bo‘lgan loyihalarda ularning tarkibini ham yuklab olish kerak. Buning uchun git clone buyrug‘ida --recurse-submodules parametri bor; undan faqat loyiha haqiqatan ham submodullarga ega bo‘lsa va ularning URL manzillari tekshirilgan bo‘lsa foydalaning. Boshqa tashqi resurslarga ega loyihalar README’da bayon qilingan qo‘shimcha amallarni talab qilishi mumkin.

Loyiha qoidalariga muvofiq bog‘liqliklarni tiklash#

Avval README va loyiha konfiguratsiya fayllarini o‘qing. Qaysi runtime versiyasi kerakligini va bog‘liqliklarni o‘rnatishda qaysi paket menejeri ishlatilishini aniqlang. Quyidagi misolda npm ko‘rsatilgani uchungina loyihaning odatiy vositasini npm bilan almashtirmang.

Node.js va npm uchun faraziy misol: repozitoriyda o‘zaro mos package.json va package-lock.json fayllari bor, serverda esa loyiha uchun mos Node.js versiyasi o‘rnatilgan. Bunday holatda loyiha papkasida quyidagini bajaring:

npm ci

npm ci hujjatlariga ko‘ra, bu buyruq bog‘liqliklarni butun loyiha uchun lockfile’dan o‘rnatadi va package.json yoki package-lock.json fayllarini qayta yozmaydi. Ularning tarkibi mos bo‘lmasa, o‘rnatish muvaffaqiyatsiz tugaydi. Mavjud node_modules papkasi o‘rnatishdan oldin o‘chiriladi.

Agar lockfile bog‘liqliklar daraxtiga ta’sir qiladigan, masalan --legacy-peer-deps kabi parametrlar bilan yaratilgan bo‘lsa, npm ci uchun ham o‘sha parametrlar kerak bo‘ladi. Manba loyihaning ko‘rsatmalari va sozlamalarini tekshiring. Birinchi ko‘chirish xatosini yashirish uchun lockfile’ni o‘chirmang yoki barcha bog‘liqliklarni yangilamang.

O‘rnatishdan oldin o‘z loyihangizdagi o‘rnatish va ishga tushirish buyruqlarini tekshiring. Ularni ishlab chiqarish ma’lumotlaridan foydalana olmaydigan alohida ishchi nusxada bajaring va kerakli muhit qiymatlarini chat hamda Git’dan tashqarida sozlang. Imkon bo‘lsa, loyihani tekshirish uchun ruxsatlari cheklangan sinov hisob ma’lumotlaridan foydalaning. Loyiha ma’lumotlar bazasi yoki fayllarga bog‘liq bo‘lsa, avval ko‘rsatmalarga muvofiq ruxsat etilgan sinov ma’lumotlar to‘plamini tiklang; bir xil manba fayllari bu ma’lumotlar o‘rnini bosmaydi.

O‘rnatishdan so‘ng README’da mavjud tekshiruvlarni bajaring: taqdim etilgan bo‘lsa, testlar va build. Buyruq nomlari loyihaga bog‘liq. Bog‘liqliklar muvaffaqiyatli o‘rnatilishi hali ilova ishlashini anglatmaydi.

Ishchi nusxani Hermes’da ochish#

Server terminalida yangi nusxaning ildiziga o‘ting va avvaldan o‘rnatilgan agentni ishga tushiring:

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

Bu yerda /absolute/path/to/my-project — loyihangizning to‘liq yo‘li o‘rnidagi belgi. Hermes ishga tushish ekranida ishchi katalogni va terminal buyruqlari bajariladigan muhitni tekshiring. Bu ishga tushirish usuli Hermes’ning serverdagi mahalliy terminal muhiti uchun mo‘ljallangan. SSH yoki Docker sozlangan bo‘lsa, agent boshqa muhitda buyruqlar bajarishi mumkin; avval o‘sha muhitda loyiha yo‘li mavjudligini tasdiqlang.

Agentdan terminal vositasi yordamida haqiqiy ishchi papkasini tasdiqlashni so‘rang, keyin README va loyiha ko‘rsatmalarini o‘qing. Xabardagi papka nomini yetarli tekshiruv deb hisoblamang.

Quyidagi tartib hujjatlarning mahkamlangan versiyasida keltirilgan va siz o‘rnatgan Hermes versiyasidan farq qilishi mumkin. Joriy seansingizdagi amaldagi ko‘rsatmalarni tekshiring. Hermes AGENTS.md faylini qo‘llab-quvvatlaydi, ammo uni o‘qishi kontekst fayllari ustuvorligiga bog‘liq. Hermes’ning rasmiy hujjatlariga ko‘ra, ko‘rsatmalar faylining bitta turi tanlanadi: .hermes.md, keyin AGENTS.override.md, AGENTS.md, CLAUDE.md va .cursorrules. Ishni boshlashdan oldin eski .hermes.md yoki shaxsiy AGENTS.override.md bor-yo‘qligini tekshiring: agent yonidagi AGENTS.md faylini albatta qo‘llaydi deb o‘ylamang.

Tanlangan ko‘rsatmalarda loyihaning maqsadi, tekshiruv buyruqlari va o‘zgarishlar bo‘yicha cheklovlarni saqlang. Ularni suhbatlar arxiviga aylantirmang. Agentlarning sozlamalarini ham ko‘chirish kerak bo‘lsa, bu boshqa jarayon; uning doirasi Claude Code’dan Codex’ga migratsiya qo‘llanmasida tushuntirilgan.

Agentga bitta vazifa bering va natijani tekshiring#

Avval hech narsani o‘zgartirmasdan loyihani o‘qib chiqing. Masalan:

Biz ko‘rsatilgan papkada mavjud loyiha bilan ishlayapmiz.
Terminal vositasidan foydalanib, haqiqiy ishchi katalogni tasdiqlang.
README va joriy loyiha ko‘rsatmalarini o‘qing.
Maxfiy ma’lumotlar saqlangan fayllarni ochmang yoki muhit o‘zgaruvchilari qiymatlarini chiqarmang.
Tekshiruv buyruqlari va ularni ishga tushirish uchun zarur shartlarni sanab bering.
Hozircha hech narsani o‘zgartirmang yoki o‘rnatmang, shuningdek, repozitoriyga push qilmang.

So‘ng interfeys matnini tuzatish kabi bitta kichik vazifani kelishib oling. O‘zgartiriladigan fayllar yoki sohani ko‘rsating, tasodifiy bog‘liqlik yangilanishlarini taqiqlang. Tajribani asosiy nusxadan ajratmoqchi bo‘lsangiz, avval alohida Git worktree ishchi nusxasi haqida bilib oling.

Natijani fayl o‘zgarishlari va loyihani qayta tekshirish asosida qabul qiling. Muvaffaqiyatsiz chiqishi mumkin bo‘lgan tajribadan oldin manba nusxasi va tiklash nuqtasini saqlang; agentdan barcha o‘zgarishlarni birdan bekor qilishni so‘ramang. Tekshiruv muvaffaqiyatsiz bo‘lsa, xatoni manba nusxasi bilan solishtiring: bu ko‘chirish muammosini avvaldan mavjud nuqsondan ajratishga yordam beradi.

Kerakli manba fayllari versiyasi joyida bo‘lsa, muhit tiklansa, zarur ma’lumotlar xavfsiz sinov muhitida mavjud bo‘lsa, tekshiruvlardan o‘tilsa va Hermes aynan shu papkada ishlayotgan bo‘lsa, ko‘chirish tugallangan hisoblanadi. Ilovani tashrif buyuruvchilar uchun nashr etish keyingi alohida bosqich bo‘lib, bu tekshiruvga kirmaydi.

Ailoot bilan tanishing.