การย้ายโปรเจกต์จาก Codex ไปยัง Hermes บนเซิร์ฟเวอร์
Markdownการย้าย repository ไปยังเซิร์ฟเวอร์เพื่อทำงานใน Hermes: การเปลี่ยนแปลงที่บันทึกไว้ dependencies ความลับ โฟลเดอร์ทำงาน และการตรวจสอบก่อนพัฒนาต่อ
อ่านบทความฉบับเต็ม
หากต้องการความช่วยเหลือในการใช้บริการ โปรดดูเอกสารประกอบ Ailoot
ประเด็นสำคัญ
หากต้องการทำงานต่อใน Hermes กับโปรเจกต์ที่สร้างด้วย Codex ให้ย้าย repository ทั้งชุดและกู้คืนสภาพแวดล้อมของโปรเจกต์ ไม่จำเป็นต้องมีขั้นตอนแยกต่างหากสำหรับ “นำเข้าโปรเจกต์จากเอเจนต์” วิธีนี้ เริ่มจากตรวจสอบไฟล์ที่บันทึกไว้และ dependencies จากนั้นเปิดโฟลเดอร์ที่ถูกต้องใน Hermes คู่มือนี้ตั้งสมมติฐานว่าได้ตั้งค่าเซิร์ฟเวอร์และ Hermes ไว้แล้ว และคุณมีสิทธิ์เข้าถึง repository
สิ่งที่ต้องเตรียมก่อนย้าย
repository คือโฟลเดอร์โปรเจกต์ที่มีประวัติการเปลี่ยนแปลงใน Git ส่วน working copy มีไฟล์ที่คุณแก้ไข งานในที่นี้คือย้าย working copy ไปยังเซิร์ฟเวอร์และทำงานพัฒนาต่อ คุณยังไม่จำเป็นต้องเผยแพร่แอปพลิเคชันให้ผู้เข้าชมใช้งาน
หากยังไม่ได้ติดตั้งเอเจนต์บนเซิร์ฟเวอร์ ให้เริ่มจากติดตั้ง Hermes Agent บน VPS ในกรณีนี้ คุณต้องมีการติดตั้ง Hermes ที่ใช้งานได้ เทอร์มินัลของเซิร์ฟเวอร์ และ Git คุณต้องมี remote repository ที่เข้าถึงได้จากเซิร์ฟเวอร์ หากยังไม่มี ให้สร้างก่อนแล้วบันทึกโปรเจกต์ไว้ที่นั่นโดยไม่มี secrets หากเป็น private repository ให้ตั้งค่าสิทธิ์อ่านจากบัญชีของคุณไว้ล่วงหน้า อย่าใส่ token ใน URL ของ repository หรือในข้อความถึงเอเจนต์
หยุดการแก้ไขโปรเจกต์พร้อมกันระหว่างการย้าย ที่คอมพิวเตอร์ต้นทาง ให้เปิดเทอร์มินัลในโฟลเดอร์โปรเจกต์โดยตรง แล้วเรียกใช้:
git status --short --branch
git status --short --ignored
คำสั่งแรกแสดง branch และสถานะของไฟล์ M หมายถึงมีการแก้ไข และ ?? หมายถึงไฟล์ที่ Git ยังไม่ได้ติดตาม ในคำสั่งที่สอง ไฟล์ที่ถูกละเว้นจะแสดงเป็น !! สถานะปกติที่สะอาดไม่ได้ยืนยันว่าไม่มีไฟล์จำเป็นที่อยู่นอก Git
บันทึกการเปลี่ยนแปลงที่จำเป็นไว้ใน commit แยกต่างหาก แล้ว push branch ที่ถูกต้องไปยัง remote repository ตามวิธีที่คุณใช้ตามปกติ ก่อน push ให้ตรวจสอบว่า commit มีอะไรบ้าง: ต้องไม่มี keys, passwords หรือข้อมูลผู้ใช้จริง หากไม่ทราบว่าควรบันทึกการเปลี่ยนแปลงใด ให้ขอให้ Codex แสดงรายการและอธิบายจุดประสงค์ก่อน โดยไม่ลบไฟล์หรือ push ไปยัง repository
| ส่วนของโปรเจกต์ | สิ่งที่ต้องตรวจสอบก่อนย้าย |
|---|---|
| ไฟล์ต้นฉบับและประวัติ Git | บันทึกการเปลี่ยนแปลงที่จำเป็นแล้ว และเข้าถึงได้ใน branch ที่เลือกของ remote repository |
| README และคำแนะนำสำหรับเอเจนต์ | มีเอกสารขั้นตอนเริ่มต้นใช้งาน การตรวจสอบ และข้อจำกัดแล้ว และคำแนะนำเป็นปัจจุบัน |
| ไฟล์ dependencies | บันทึกคำจำกัดความ dependencies และ lockfile ที่โปรเจกต์ใช้ ซึ่งเป็นไฟล์ที่กำหนดเวอร์ชันไว้แล้ว |
| Secrets | มีวิธีแยกต่างหากที่ปลอดภัยสำหรับตั้งค่าบนเซิร์ฟเวอร์ ค่าเหล่านี้ไม่ได้อยู่ใน Git หรือถูกส่งผ่านแชต |
| ฐานข้อมูลและไฟล์ที่อัปโหลด | คุณทราบว่าจะรับข้อมูลทดสอบที่อนุญาตได้จากที่ใด และจะกู้คืนโดยใช้คำแนะนำของโปรเจกต์ได้อย่างไร |
อย่าคิดว่าการ clone repository จะย้ายฐานข้อมูลภายนอก เนื้อหาในโฟลเดอร์ที่ถูกละเว้น หรือบทสนทนาของคุณกับ Codex มาด้วย ประวัติแชต การสมัครใช้งาน โปรไฟล์ และการตั้งค่าของเอเจนต์เองไม่รวมอยู่ในวิธีการย้ายนี้
คัดลอก branch ที่ถูกต้องไปยังเซิร์ฟเวอร์
ขั้นแรก ให้บันทึกผลลัพธ์ของคำสั่งนี้ไว้ที่คอมพิวเตอร์ต้นทาง:
git status --porcelain=v2 --branch
บรรทัด # branch.oid แสดง commit ปัจจุบัน ส่วน # branch.head แสดง branch commit คือเวอร์ชันที่บันทึกไว้ของโปรเจกต์ สำหรับโปรเจกต์ทั่วไปที่มี commit อยู่แล้ว วิธีนี้ช่วยให้คุณเปรียบเทียบสำเนาต้นทางกับสำเนาใหม่ได้ แต่การเปรียบเทียบนี้จะไม่ตรวจสอบการเปลี่ยนแปลงที่ยังไม่ได้ commit
บนเซิร์ฟเวอร์ ให้ไปยังไดเรกทอรีที่จะจัดเก็บโปรเจกต์ของคุณ clone repository ไปยังโฟลเดอร์ใหม่ ในเทมเพลตด้านล่าง ให้แทน REPOSITORY_URL ด้วย URL ของ repository ของคุณ แทน BRANCH_NAME ด้วยชื่อ branch ที่คุณบันทึกและ push แล้ว และแทน my-project ด้วยชื่อที่ต้องการใช้กับโฟลเดอร์ใหม่:
git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch
นี่เป็นเทมเพลต ไม่ใช่ URL สำเร็จรูปที่คัดลอกไปใช้ได้ git clone จะสร้างโฟลเดอร์และ working copy ของ branch ที่เลือก หากโฟลเดอร์ปลายทางมีอยู่แล้ว โฟลเดอร์นั้นต้องว่างเปล่า: อย่าลบเนื้อหาเพื่อเรียกใช้คำสั่งซ้ำ ให้เลือกชื่อใหม่
เปรียบเทียบ # branch.oid ในสำเนาทั้งสอง หากค่าไม่ตรงกัน อย่าเริ่มแก้โค้ดบนเซิร์ฟเวอร์: ตรวจสอบ branch ที่เลือก commit ที่ push ไป และว่ามีการเปลี่ยนแปลงพร้อมกันหรือไม่ หากผลลัพธ์สถานะแสดงไฟล์ที่ถูกแก้ไข ให้ตรวจสอบแยกต่างหาก อย่าใช้การล้างข้อมูลหรือการ reset แบบบังคับเพื่อ “ทำให้ตรงกัน”
repository ที่มี Git submodules ซึ่งเป็น repository ที่ซ้อนอยู่ภายใน ต้องดึงเนื้อหาของ submodules มาด้วย git clone มีตัวเลือก --recurse-submodules สำหรับกรณีนี้ ให้ใช้เมื่อโปรเจกต์มี submodules จริงและตรวจสอบ URL ของ submodules แล้ว โปรเจกต์ที่ใช้ทรัพยากรภายนอกอื่นอาจต้องดำเนินการเพิ่มเติมตามที่อธิบายไว้ใน README
กู้คืน dependencies ตามกฎของโปรเจกต์
ขั้นแรก ให้อ่าน README และไฟล์กำหนดค่าของโปรเจกต์ ตรวจสอบว่าต้องใช้ runtime เวอร์ชันใด และใช้ package manager ใดติดตั้ง dependencies อย่าเปลี่ยนเครื่องมือปกติของโปรเจกต์ไปใช้ npm เพียงเพราะมีตัวอย่างด้านล่าง
ตัวอย่างสมมติสำหรับ Node.js และ npm: repository มีไฟล์ package.json และ package-lock.json ที่สอดคล้องกัน และติดตั้ง Node.js เวอร์ชันที่เหมาะกับโปรเจกต์ไว้บนเซิร์ฟเวอร์แล้ว ในกรณีนี้ ให้เรียกใช้คำสั่งนี้ในโฟลเดอร์โปรเจกต์:
npm ci
ตามเอกสาร npm ci คำสั่งนี้ติดตั้ง dependencies สำหรับทั้งโปรเจกต์จาก lockfile โดยไม่เขียนทับ package.json หรือ package-lock.json หากเนื้อหาในไฟล์ทั้งสองไม่สอดคล้องกัน การติดตั้งจะล้มเหลว โฟลเดอร์ node_modules ที่มีอยู่จะถูกลบก่อนติดตั้ง
หากสร้าง lockfile ด้วยตัวเลือกที่ส่งผลต่อต้นไม้ dependencies เช่น --legacy-peer-deps คำสั่ง npm ci ต้องใช้ตัวเลือกเดียวกัน ตรวจสอบคำแนะนำและการตั้งค่าของโปรเจกต์ต้นทาง อย่าลบ lockfile หรืออัปเดต dependencies ทั้งหมดเพื่อปกปิดข้อผิดพลาดแรกที่เกิดขึ้นระหว่างการย้าย
ก่อนติดตั้ง ให้ตรวจสอบคำสั่งติดตั้งและเริ่มต้นใช้งานในโปรเจกต์ของคุณ เรียกใช้คำสั่งเหล่านั้นใน working copy แยกต่างหากที่ไม่มีสิทธิ์เข้าถึงข้อมูล production และกำหนดค่าตัวแปรสภาพแวดล้อมที่จำเป็นนอกแชตและ Git หากทำได้ ให้ใช้ข้อมูลรับรองสำหรับการทดสอบที่มีสิทธิ์จำกัดเพื่อตรวจสอบโปรเจกต์ หากโปรเจกต์ต้องใช้ฐานข้อมูลหรือไฟล์ ให้กู้คืนชุดข้อมูลทดสอบที่ได้รับอนุญาตตามคำแนะนำก่อน เพราะไฟล์ต้นฉบับที่เหมือนกันใช้แทนข้อมูลดังกล่าวไม่ได้
หลังติดตั้ง ให้เรียกใช้การตรวจสอบที่มีอยู่ใน README ได้แก่ tests และ build หากมี คำสั่งจะแตกต่างกันไปตามโปรเจกต์ การติดตั้ง dependencies สำเร็จไม่ได้หมายความว่าแอปพลิเคชันใช้งานได้แล้ว
เปิด working copy ใน Hermes
ในเทอร์มินัลของเซิร์ฟเวอร์ ให้ไปยัง root ของสำเนาใหม่ แล้วเริ่มเอเจนต์ที่ติดตั้งไว้แล้ว:
cd /absolute/path/to/my-project
hermes
ในที่นี้ /absolute/path/to/my-project เป็น placeholder สำหรับ path เต็มของโปรเจกต์ บนหน้าจอเริ่มต้นของ Hermes ให้ตรวจสอบ working directory และสภาพแวดล้อมที่ใช้เรียกคำสั่งเทอร์มินัล วิธีเริ่มต้นนี้มีไว้สำหรับสภาพแวดล้อมเทอร์มินัลภายในของ Hermes บนเซิร์ฟเวอร์ หากกำหนดค่า SSH หรือ Docker ไว้ เอเจนต์อาจเรียกใช้คำสั่งในสภาพแวดล้อมอื่น ให้ยืนยันก่อนว่า path ของโปรเจกต์เข้าถึงได้ในสภาพแวดล้อมนั้น
ขอให้เอเจนต์ยืนยันโฟลเดอร์ทำงานจริงโดยใช้เครื่องมือเทอร์มินัลของเอเจนต์ จากนั้นให้อ่าน README และคำแนะนำของโปรเจกต์ อย่าถือว่าชื่อโฟลเดอร์ในข้อความเป็นการยืนยันที่เพียงพอ
ลำดับด้านล่างระบุไว้ในเอกสารเวอร์ชันที่ระบุ commit ไว้ และอาจแตกต่างจาก Hermes เวอร์ชันที่ติดตั้งอยู่ของคุณ ตรวจสอบคำแนะนำปัจจุบันในเซสชันของคุณ Hermes รองรับ AGENTS.md แต่จะอ่านไฟล์นั้นหรือไม่ขึ้นอยู่กับลำดับความสำคัญของไฟล์ context ตามเอกสาร Hermes อย่างเป็นทางการ ระบบจะเลือกไฟล์คำแนะนำประเภทหนึ่งตามลำดับนี้: .hermes.md ตามด้วย AGENTS.override.md, AGENTS.md, CLAUDE.md และ .cursorrules ก่อนเริ่มงาน ให้ตรวจสอบว่ามี .hermes.md เก่าหรือ AGENTS.override.md ส่วนตัวหรือไม่: อย่าคิดว่าเอเจนต์จะอ่าน AGENTS.md ควบคู่กับไฟล์ดังกล่าวเสมอไป
ในคำแนะนำที่ถูกเลือก ให้คงวัตถุประสงค์ของโปรเจกต์ คำสั่งตรวจสอบ และข้อจำกัดในการเปลี่ยนแปลงไว้ อย่าเปลี่ยนให้กลายเป็นคลังบทสนทนา หากต้องการย้ายการตั้งค่าของเอเจนต์เอง นั่นเป็นอีกกระบวนการหนึ่ง โดยอธิบายขอบเขตไว้ในคู่มือการย้ายจาก Claude Code ไปยัง Codex
มอบหมายงานหนึ่งอย่างให้เอเจนต์และตรวจสอบผลลัพธ์
เริ่มจากอ่านโปรเจกต์โดยไม่แก้ไขอะไร ตัวอย่างเช่น:
เรากำลังทำงานกับโปรเจกต์ที่มีอยู่ในโฟลเดอร์ที่ฉันระบุ
ยืนยันไดเรกทอรีทำงานจริงโดยใช้เครื่องมือเทอร์มินัล
อ่าน README และคำแนะนำโปรเจกต์ฉบับปัจจุบัน
อย่าเปิดไฟล์ที่มี secrets หรือแสดงค่าตัวแปรสภาพแวดล้อม
ระบุคำสั่งตรวจสอบและข้อกำหนดเบื้องต้นสำหรับการเรียกใช้
ตอนนี้อย่าแก้ไขหรือติดตั้งอะไร และอย่า push ไปยัง repository
จากนั้นตกลงกันในงานเล็ก ๆ หนึ่งอย่าง เช่น แก้ข้อความในอินเทอร์เฟซ ระบุไฟล์หรือส่วนที่จะเปลี่ยน และห้ามอัปเดต dependencies โดยไม่ได้ตั้งใจ หากต้องการแยกการทดลองออกจากสำเนาหลัก ให้ศึกษาวิธีใช้ working copy แยกต่างหากด้วย Git worktree ก่อน
ยอมรับผลลัพธ์โดยพิจารณาจากการเปลี่ยนแปลงของไฟล์และการตรวจสอบโปรเจกต์ที่ทำซ้ำ ก่อนการทดลองที่อาจไม่สำเร็จ ให้บันทึกสำเนาต้นทางและจุดกู้คืน อย่าขอให้เอเจนต์ reset การเปลี่ยนแปลงทั้งหมดพร้อมกัน หากการตรวจสอบล้มเหลว ให้เปรียบเทียบข้อผิดพลาดกับสำเนาต้นทาง วิธีนี้ช่วยแยกปัญหาจากการย้ายออกจากข้อบกพร่องที่มีอยู่ก่อนแล้ว
ถือว่าการย้ายเสร็จสมบูรณ์ได้เมื่อมีไฟล์ต้นฉบับเวอร์ชันที่ต้องการอยู่ครบแล้ว กู้คืนสภาพแวดล้อมแล้ว มีข้อมูลที่จำเป็นในสภาพแวดล้อมทดสอบที่ปลอดภัย การตรวจสอบผ่าน และ Hermes ทำงานอยู่ในโฟลเดอร์นี้อย่างแน่นอน การเผยแพร่แอปพลิเคชันให้ผู้เข้าชมเป็นขั้นตอนถัดไปแยกต่างหาก และไม่รวมอยู่ในการตรวจสอบนี้
มาทำความรู้จักกับ Ailoot
รายละเอียดเพิ่มเติม
คำถามที่พบบ่อย
clone repository แล้วย้ายสภาพแวดล้อมทำงานมาทั้งหมดหรือไม่?
ไม่ทั้งหมด Git ไม่ย้ายไฟล์ที่ ignore ฐานข้อมูลภายนอก ข้อมูลอัปโหลด ความลับ หรือประวัติแชตเอเจนต์ ต้องคืน dependencies และข้อมูลทดสอบที่อนุญาตแยกตามคำสั่งโปรเจกต์
ควรเปรียบเทียบอะไรก่อนแก้สำเนาบนเซิร์ฟเวอร์?
เทียบ branch และ commit ที่บันทึกไว้กับสำเนาต้นทาง ตรวจการเปลี่ยนแปลงที่ยังไม่ commit และให้ Hermes ยืนยันโฟลเดอร์ทำงานจริง แล้วรันการตรวจที่โปรเจกต์มีอยู่ในสำเนานั้นโดยตรง