GitHub PR + Preview Release Workflow สำหรับ Non-Coder | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand
$ cat appendix-g-github-pr-preview-workflow.md
GitHub PR + Preview Release Workflow สำหรับ Non-Coder ใช้ appendix นี้เมื่อไหร่
ใช้เมื่อ project เริ่มมีคนใช้ หรือเริ่ม deploy ไป Vercel แล้ว
เป้าหมายคือไม่แก้ทุกอย่างบน main ตรง ๆ
แต่ใช้ workflow ที่ปลอดภัยกว่า:
branch → change → commit → push → PR → preview → review → merge → production คัดลอก สำหรับ non-coder ให้คิดแบบนี้:
branch = ห้องทดลอง PR = ใบส่งงานให้ตรวจ preview = URL ทดสอบ main = ของจริงที่พร้อม deploy คัดลอก ทำไมไม่แก้บน main ตรง ๆ
ถ้า Vercel ผูกกับ GitHub แล้ว main มักเป็น production branch
แปลว่า:
push เข้า main → Vercel อาจ deploy production คัดลอก ถ้าคุณแก้ผิดแล้ว push เข้า main โดยไม่ test preview ก่อน user จริงอาจเจอ bug ทันที
ดังนั้นสำหรับงานที่ไม่ใช่แก้ typo เล็กมาก ให้ใช้ branch + PR
คำศัพท์ที่ต้องรู้
คำ แปลแบบง่าย Repository กล่องเก็บ code บน GitHub main branch หลัก มักใช้ deploy production branch พื้นที่แยกสำหรับแก้งานหนึ่งเรื่อง commit save point ของ code push ส่ง commit จากเครื่องขึ้น GitHub pull request / PR หน้าตรวจ change ก่อน merge merge เอา change เข้า main preview deployment URL ทดสอบที่ Vercel สร้างจาก branch/PR production deployment URL จริงที่ user ใช้
Workflow ภาพรวม 1. เลือกงานเล็ก 1 เรื่อง 2. สร้าง branch ใหม่ 3. ให้ Claude แก้เฉพาะ scope นั้น 4. review diff 5. commit 6. push branch 7. เปิด PR บน GitHub 8. ดู Vercel preview URL 9. test preview 10. ถ้าผ่าน merge เข้า main 11. test production หลัง deploy 12. จด release note คัดลอก อย่ารวม 5 feature ใน PR เดียวถ้าไม่จำเป็น
รอบนี้แก้อะไร และทำไม คัดลอก
Step 1 — เลือก scope ให้เล็ก fix duplicate email message improve mobile hero spacing add waitlist success state hide dashboard link for public users คัดลอก ตัวอย่าง scope ที่ใหญ่เกิน:
ปรับเว็บให้ดีขึ้นทั้งหมด ทำ dashboard ใหม่ทั้งระบบ เพิ่ม login payment และ admin panel คัดลอก ช่วยแยกงานนี้ให้เป็น PR scope ที่เล็กพอ งานที่อยากทำ: [อธิบาย] กติกา: - แยกเป็น PR ย่อย ๆ ถ้าจำเป็น - แต่ละ PR ต้องมี goal เดียว - บอก risk ของแต่ละ PR - แนะนำลำดับทำก่อนหลัง คัดลอก
Step 2 — สร้าง branch ชื่อ branch ควรอ่านแล้วรู้ว่าทำอะไร
fix-waitlist-duplicate-message improve-mobile-landing-page add-preview-test-checklist secure-dashboard-access คัดลอก git checkout main git pull git checkout -b fix-waitlist-duplicate-message คัดลอก ถ้าคุณไม่มั่นใจ ให้ Claude ช่วยแปล command ก่อนรัน:
ช่วยอธิบายคำสั่ง Git เหล่านี้ทีละบรรทัดแบบ non-coder และบอกว่ามีความเสี่ยงอะไรไหม Commands: [paste commands] คัดลอก
Step 3 — ให้ Claude แก้เฉพาะ branch นี้ เรากำลังทำ branch: [branch name] Task: [สิ่งที่ต้องแก้] กติกา: - แก้เฉพาะ scope นี้ - อย่าเพิ่ม feature ใหม่ - อย่า refactor ส่วนอื่น - ถ้าต้องเพิ่ม package/env var/database change ให้หยุดถามก่อน - หลังแก้ให้สรุป diff และ manual test คัดลอก ถ้า Claude เริ่มแตะไฟล์เยอะผิดปกติ ให้หยุดและถาม:
ทำไม task นี้ต้องแก้ไฟล์เยอะขนาดนี้ มีวิธีแก้ที่เปลี่ยนน้อยกว่านี้ไหม คัดลอก
Step 4 — Review diff ก่อน commit ก่อน commit ต้องดูว่า AI เปลี่ยนอะไร
ช่วย review diff ปัจจุบันก่อน commit ตรวจว่า: 1. เปลี่ยนไฟล์อะไรบ้าง 2. แต่ละไฟล์เปลี่ยนเพื่ออะไร 3. มี change นอก scope ไหม 4. มี secret/.env/key หลุดไหม 5. มี package ใหม่ไหม 6. มีผลต่อ database/auth/RLS/deploy ไหม 7. ต้อง test อะไร 8. commit message ควรเป็นอะไร ถ้ามี red flag ให้บอกให้หยุดก่อน commit คัดลอก [ ] ไม่มี .env [ ] ไม่มี secret key [ ] ไม่มี service_role ใน frontend [ ] ไม่มี package แปลก ๆ [ ] ไม่แตะไฟล์นอก scope [ ] test checklist ชัดเจน คัดลอก
Step 5 — Commit งานย่อยจบ diff เข้าใจได้ test ขั้นต่ำผ่าน ไม่มี red flag คัดลอก fix: handle duplicate waitlist emails feat: add waitlist success state docs: add deploy checklist chore: remove unused dependency คัดลอก ช่วยตั้ง commit message สำหรับ changes นี้ ใช้ Conventional Commits ให้เลือก 2–3 ตัวเลือก พร้อมเหตุผลสั้น ๆ คัดลอก git status git add [files] git commit -m "fix: handle duplicate waitlist emails" คัดลอก อย่า git add . ถ้าคุณยังไม่ได้ดูว่ามีไฟล์อะไรบ้าง
Step 6 — Push branch ขึ้น GitHub หลัง commit แล้ว push branch:
git push -u origin fix-waitlist-duplicate-message คัดลอก ถ้า error ให้ copy error มาให้ Claude วิเคราะห์ก่อน
git push fail ช่วยอธิบาย error นี้แบบ non-coder และบอกวิธีแก้ที่ปลอดภัย Command: [paste command] Error: [paste error] อย่าเสนอ force push เว้นแต่จำเป็นจริง ๆ และอธิบายความเสี่ยงก่อน คัดลอก
Step 7 — เปิด Pull Request บน GitHub หลัง push branch มักมีปุ่มให้เปิด PR
ทำอะไร ทำไมต้องทำ เปลี่ยนไฟล์สำคัญอะไร test อะไรแล้ว preview URL คืออะไร risk ที่ reviewer ควรดู คัดลอก ## What changed - [change 1] - [change 2] ## Why [ เหตุผล ] ## Scope This PR only covers: - [ scope ] Out of scope: - [not included] ## Test plan - [ ] local test - [ ] preview test - [ ] mobile check - [ ] form validation - [ ] security/data check if relevant ## Preview URL [ URL ] ## Risks / reviewer notes - [risk 1] - [risk 2] ## Screenshots [before/after if UI] คัดลอก ช่วยเขียน PR description สำหรับ changes นี้ ใช้ template: - What changed - Why - Scope - Test plan - Preview URL placeholder - Risks / reviewer notes - Screenshots เขียนให้ non-coder และ reviewer เข้าใจ คัดลอก
Step 8 — ดู Vercel Preview URL ถ้า Vercel เชื่อมกับ GitHub แล้ว เมื่อเปิด PR หรือ push branch Vercel จะสร้าง preview deployment
GitHub PR checks/comments Vercel dashboard > Deployments คัดลอก ใช้ preview URL เพื่อ test ก่อน merge
อย่าคิดว่า “build ผ่าน = ใช้ได้”
ต้องเปิด URL และลอง flow จริง
Step 9 — Preview test checklist ใช้ checklist นี้กับ PR ทุกอัน
Basics [ ] Preview URL เปิดได้ [ ] ไม่มี blank screen [ ] ไม่มี obvious layout break Scope [ ] change ที่ตั้งใจทำงานจริง [ ] ไม่มี feature นอก scope โผล่ Mobile [ ] mobile size อ่านได้ [ ] ปุ่มกดง่าย [ ] form ใช้ได้ Data/security ถ้าเกี่ยวข้อง [ ] ไม่มี secret ใน UI/error [ ] form validation ทำงาน [ ] user เห็นเฉพาะข้อมูลที่ควรเห็น [ ] RLS/auth ไม่ถูกปิดหรือ bypass Regression [ ] flow หลักเดิมยังทำงาน [ ] หน้าอื่นที่เกี่ยวข้องไม่พัง คัดลอก ช่วยทำ preview test plan สำหรับ PR นี้ PR scope: [scope] ให้แยกเป็น: 1. test ที่ต้องทำแน่นอน 2. test ที่เกี่ยวกับ security/data 3. regression test ที่ควรทำ 4. test ที่ไม่จำเป็นในรอบนี้ คัดลอก
Step 10 — ถ้า preview fail preview URL สิ่งที่กด expected actual console/network error Vercel log ถ้ามี คัดลอก Preview deployment fail หรือใช้แล้วพัง ช่วย debug จาก evidence นี้ PR: [PR link/title] Preview URL: [URL] Expected: [ควรเกิดอะไร] Actual: [เกิดอะไร] Evidence: [paste log/error] กติกา: - อย่า merge - วิเคราะห์ก่อนแก้ - แก้เฉพาะ PR scope - หลังแก้ให้บอกว่าต้อง push update แล้ว test preview อะไรซ้ำ คัดลอก เมื่อแก้แล้ว commit/push ใหม่ใน branch เดิม Vercel จะสร้าง preview ใหม่
Step 11 — Merge เข้า main [ ] PR scope ชัด [ ] preview test ผ่าน [ ] ไม่มี blocker [ ] ไม่มี secret/data risk [ ] ถ้ามี reviewer เขา approve แล้ว คัดลอก หลัง merge เข้า main Vercel มักสร้าง production deployment จาก main
ต้อง test production หลัง merge
Step 12 — Production smoke test หลัง merge หลัง production deploy เสร็จ ให้ test 5 นาที
[ ] production URL เปิดได้ [ ] change ที่ merge มาอยู่จริง [ ] flow หลักยังทำงาน [ ] form/API/database ยังทำงาน [ ] mobile ไม่พัง [ ] ไม่มี error ใหม่ คัดลอก ถ้ากระทบ user จริง → พิจารณา rollback ถ้าไม่กระทบหนัก → hotfix branch ใหม่ คัดลอก production หลัง merge มีปัญหา ช่วยประเมิน rollback vs hotfix PR ที่ merge: [link/title] Production issue: [อธิบาย] Evidence: [log/error] Impact: [ใครกระทบ] กติกา: - ลดผลกระทบ user ก่อน - ถ้า hotfix ให้ใช้ branch ใหม่ ไม่แก้มั่วบน main คัดลอก
Release note หลัง merge จดสั้น ๆ เพื่อให้คุณในอนาคตรู้ว่า deploy อะไร
# Release Note ## Date/time [ date ] ## PR [PR link] ## Production URL [ URL ] ## What shipped - [ change ] ## Tests done - [ ] preview test - [ ] production smoke test - [ ] mobile - [ ] data/security if relevant ## Result [pass / issue / rollback] ## Follow-up - [ TODO ] คัดลอก
ถ้าทำงานคนเดียว ยังต้อง PR ไหม? แต่แนะนำใช้ PR ถ้า change มีสิ่งเหล่านี้:
database
auth/permission
env var
deploy config
payment
dashboard/admin
user data
package ใหม่
UI flow สำคัญ
ถ้าเป็น typo หรือ copy เล็กมาก อาจ commit เข้า main ได้ แต่ต้องรู้ว่า production อาจ deploy ตาม
ใช้ Claude Code Review ได้ไหม? Claude Code มี feature Code Review สำหรับ GitHub PR ในบางแผน/องค์กร และสถานะบางอย่างอาจเป็น preview/research preview ตาม official docs
สำหรับหนังสือเล่มนี้ ให้ถือว่าเป็น optional
สิ่งที่ควรทำเสมอแม้ไม่มี automated review:
ให้ Claude ใน local review diff ดู PR files changed ด้วยตัวเอง test preview URL ไม่ merge ถ้ายังมี red flag คัดลอก ช่วย review PR นี้จาก diff ปัจจุบัน หา: - bug ที่เป็นไปได้ - regression - security/data risk - missing validation - env var issue - test ที่ขาด ตอบเป็น Critical / High / Medium / Low อย่าแก้ไฟล์ก่อน คัดลอก
Common problems
Problem 1: ไม่รู้ว่าอยู่ branch ไหน git branch --show-current คัดลอก ช่วยอธิบายผล git branch --show-current นี้ และบอกว่าฉันกำลังแก้บน main หรือ branch อื่น คัดลอก
Problem 2: มีไฟล์แปลก ๆ ติดมาใน PR ช่วยดู git status และบอกว่าไฟล์ไหนเกี่ยวกับ task นี้ ไฟล์ไหนน่าสงสัย อย่า stage หรือ commit เอง คัดลอก
Problem 3: merge แล้ว production พัง ใช้ Appendix F เก็บ evidence และ Appendix D เรื่อง rollback
อย่า push hotfix มั่ว ๆ เข้า main โดยไม่มี test
Problem 4: PR ใหญ่เกินไป PR นี้ใหญ่เกินไป ช่วยแยก changes เป็น PR ย่อยตาม scope และ risk บอกว่าอันไหนควรทำก่อนหลัง คัดลอก
Problem 5: conflict ตอน merge สำหรับ non-coder ถ้า conflict เยอะ ให้หยุดและให้ Claude อธิบายก่อน
เกิด merge conflict ช่วยอธิบายว่า conflict อยู่ไฟล์ไหน และเกี่ยวกับอะไร อย่าแก้เองจนกว่าจะเสนอ plan ถ้า conflict เสี่ยงกับ data/auth/security ให้บอกให้ human review คัดลอก
Final PR + Preview checklist Before work [ ] scope เล็กและชัด [ ] branch ใหม่จาก main ล่าสุด Before commit [ ] diff review แล้ว [ ] ไม่มี secret/.env [ ] ไม่มี change นอก scope [ ] test local ที่จำเป็นผ่าน Before PR [ ] push branch แล้ว [ ] PR description ชัด [ ] test plan ชัด Before merge [ ] preview deployment ผ่าน [ ] preview URL test แล้ว [ ] security/data check ผ่านถ้าเกี่ยวข้อง [ ] ไม่มี blocker After merge [ ] production deploy ผ่าน [ ] production smoke test ผ่าน [ ] release note เขียนแล้ว [ ] ถ้าพัง มี rollback/hotfix plan คัดลอก
Prompt รวมท้าย appendix ใช้ prompt นี้เมื่อจะเริ่มงานรอบใหม่
ช่วยเป็น release workflow assistant ฉันเป็น non-coder Task: [อธิบายงาน] ช่วยพาฉันทำแบบ branch → PR → preview → merge ก่อนเริ่ม: - แนะนำ branch name - แนะนำ scope ที่เล็กพอ - บอก risk - บอก test plan ระหว่างทำ: - review diff ก่อน commit - เตือนถ้ามี secret/package/env/database/auth/deploy change - ช่วยเขียน commit message และ PR description ก่อน merge: - สร้าง preview test checklist - บอก blocker ถ้ามี หลัง merge: - สร้าง production smoke test checklist - ช่วยเขียน release note กติกา: - อย่า push/merge/deploy เองถ้าฉันยังไม่ approve - ถ้าต้อง force push ให้หยุดและอธิบายความเสี่ยงก่อน - ถ้าเกี่ยวกับ data/security/payment ให้แนะนำ human review ถ้าจำเป็น คัดลอก อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย