บทที่ 4 — Branch workflow: กติกาที่ทั้งทีมต้องเดินตาม

ทำไมต้องมี branch

ถ้าทุกคน commit ลงเส้นเดียวกันหมด งานครึ่ง ๆ กลาง ๆ ของคนหนึ่งจะไปพังงานของอีกคนทันที และถ้าโค้ดเส้นนั้นคือเส้นที่ใช้ deploy ขึ้นเว็บจริง เท่ากับความพังไปโผล่หน้าลูกค้าเลย

branch คือการก๊อปปี้เส้นเวลาออกมาทำงานของตัวเอง พังยังไงก็อยู่ในเส้นตัวเอง พอเสร็จและผ่านการตรวจแล้วค่อยรวมกลับเข้าเส้นหลัก

เส้นทางเดินของโค้ดในโปรเจกต์นี้

git checkout develop && git pull
git checkout -b feat/product-filter

กฎ 5 ข้อของ repo นี้

เขียนไว้ใน AGENTS.md หัวข้อ MANDATORY: branch per task — ทั้งคนและ AI ที่ทำงานใน repo นี้ต้องทำตาม

1. หนึ่ง branch = หนึ่งงาน อย่าเอางานไม่เกี่ยวกันมายัดรวม
2. แตก branch ใหม่จาก develop ที่อัปเดตล่าสุดเสมอ อย่าใช้ branch เก่าที่ค้างอยู่
3. ห้าม commit ตรงเข้า develop / uat / main เด็ดขาด เข้าได้ทาง PR ทางเดียว
4. ถ้าเผลออยู่ผิด branch ตอนเริ่มงาน ให้สลับ/แตกใหม่ก่อน แล้วค่อยแก้ไฟล์
5. typecheck / lint / build ต้องผ่านก่อนเปิด PR

ชื่อ branch

ใช้รูปแบบ ประเภท/สิ่งที่ทำ-สั้น-ๆ เป็นภาษาอังกฤษ ขีดกลางคั่นคำ

feat/product-filter-by-brand     ฟีเจอร์ใหม่
fix/cart-badge-not-updating      แก้บั๊ก
chore/upgrade-tailwind           งานบ้าน ไม่กระทบผู้ใช้
docs/learning-site               เอกสาร

ทำจริงทีละขั้น

# 1. กลับไปที่ develop แล้วดึงของล่าสุด (ข้อ 2 ของกฎ)
git checkout develop
git pull

# 2. แตก branch ของงานนี้
git checkout -b feat/product-filter-by-brand

# 3. ทำงาน... commit ไปเรื่อย ๆ ระหว่างทาง
git add .
git commit -m "Add brand filter to catalogue sidebar"

# 4. ตรวจงานตัวเองก่อนส่ง (ข้อ 5)
npx tsc --noEmit      # เช็ค type
npm run lint          # เช็คสไตล์โค้ด
npm run build         # ลอง build จริง

# 5. ส่งขึ้น GitHub
git push -u origin feat/product-filter-by-brand

แล้ว pull request?

PR คือการบอกว่า "งานผมเสร็จ ขอรวมเข้า develop หน่อย" — และเป็นจุดที่เกิด 2 อย่างพร้อมกัน: CI ตรวจอัตโนมัติ (บทที่ 7–8) กับ คนรีวิว

เปิดผ่านหน้าเว็บ GitHub ก็ได้ หรือใช้คำสั่ง:

gh pr create --base develop --title "Add brand filter to catalogue" --body "อธิบายว่าทำอะไร ทำไม ทดสอบยังไง"
gh pr checks --watch    # ดูผล CI แบบเรียลไทม์
gh pr merge <เลข PR> --merge --delete-branch

เขียน PR ยังไงให้คนรีวิวง่าย: บอก 3 อย่างพอ — ทำอะไร, ทำไมต้องทำ, ทดสอบยังไงแล้วบ้าง ลองเปิดดู PR เก่าของ repo นี้เป็นตัวอย่างได้ที่ https://github.com/Natt-Woramet/apexhuas/pulls

หลัง merge แล้วเก็บกวาด

git checkout develop
git pull                 # ดึงงานที่เพิ่ง merge ลงมา
git fetch --prune        # ลบ branch ที่ถูกลบบน GitHub ออกจากรายชื่อในเครื่อง

จังหวะที่ของขึ้นเว็บจริง

เมื่องานใน develop พร้อมให้ลูกค้าดู เราเปิด PR จาก develop → uat พอ merge ปุ๊บ ระบบจะ build แล้ว deploy ให้เอง เว็บ https://apexhuas.choiceflowhub.com จะเปลี่ยนภายในไม่กี่นาที (รายละเอียดในบทที่ 11)

สำคัญ: เพราะแบบนี้ การ merge เข้า uat จึงไม่ใช่แค่ "รวมโค้ด" แต่คือ การเผยแพร่ต่อสาธารณะ promote เฉพาะงานที่เสร็จจริงและ CI เขียวเท่านั้น

ลองทำเอง: ฝึกทั้งวงจรด้วยงานเล็ก ๆ — แตก branch docs/my-first-pr แล้วแก้ไฟล์ README.md เพิ่มชื่อตัวเองสักบรรทัด → commit → push → เปิด PR เข้า develop → ดู CI รันจนเขียว → ปิด PR ทิ้งไปเลยก็ได้ (กด Close ไม่ต้อง merge) เป้าหมายคือให้เห็นวงจรครบ ไม่ใช่ได้โค้ด

เจอปัญหาบ่อย ๆ

บทหน้าเข้าเรื่องที่ทำให้ทั้งหมดนี้ปลอดภัยจริง: ระบบตรวจงานอัตโนมัติที่ยืนเฝ้าอยู่หน้าประตู develop