Gitflow ออกแบบมาเพื่อใคร
Gitflow ที่หลายคนรู้จัก (main, develop, feature/*, release/*, hotfix/*) ออกแบบโดย Vincent Driessen ปี 2010 สำหรับยุคที่ software มี release cycle ยาว (3-6 เดือน), deploy เป็น packaged installer
ตอนนี้ปี 2026 — เรา deploy หลายครั้งต่อวัน ใช้ container ใช้ CI/CD Gitflow เลยกลายเป็น overkill
แม้แต่ Vincent คนเขียน Gitflow เอง ก็ออกมาบอกในปี 2020 ว่าถ้าทีมทำ web app + deploy บ่อย ใช้ Gitflow ก็ overkill ใช้ trunk-based ดีกว่า
ปัญหาที่เห็นในทีมเล็กที่ใช้ Gitflow
ในทีมขนาด 3-5 คนที่ใช้ Gitflow มักเจอปัญหาเหล่านี้:
- Branch หลัก 2 ตัว (
main,develop) สับสนว่าทำไมต้องมี — feature ส่วนใหญ่ merge เข้า develop แล้วก็ทุกอันก็ไป main อยู่ดี - Release branch กิน lead time — feature เสร็จในวันจันทร์ แต่กว่าจะ merge ไป main ต้องรอ release branch สิ้นเดือน
- Hotfix process ซับซ้อน — ต้องไป branch จาก main แก้ merge กลับ main แล้ว cherry-pick กลับไป develop ลืมขั้นไหนก็ลืมไปเลย
- Branch อายุยาว = merge conflict ใหญ่ — feature 2 อาทิตย์ค่อย merge เจอ conflict กับ feature คนอื่นทุกครั้ง
Trunk-Based Development คืออะไร
หลักการสั้นๆ:
ทุกคน commit ลง main branch บ่อยๆ branch ใดๆ ต้องอายุไม่เกิน 1-2 วัน
Branch รูปแบบเดียว: main (หรือ trunk) — feature, fix, hotfix ทั้งหมด branch จาก main แล้วก็กลับเข้า main เร็วที่สุด
main ←── feature/login-google (1 วัน)
main ←── fix/cart-total-bug (3 ชั่วโมง)
main ←── chore/upgrade-next (1 วัน)
main ←── feature/payment-flow (2 วัน, ใช้ feature flag)
ภาพรวม:
main: ●──●──●──●──●──●──●──●──●→
↑ ↑ ↑
merge merge merge
feat fix feat
Workflow ในทีม
ขั้นที่ 1: pull main ก่อนเริ่มงาน
git checkout main
git pull origin main
git checkout -b feature/add-search
ขั้นที่ 2: commit เล็กๆ บ่อยๆ
แทนที่จะ commit ใหญ่ก้อนเดียว แบ่งเป็น chunk ที่อ่านง่าย:
git commit -m "feat: add search input UI"
git commit -m "feat: wire up search API call"
git commit -m "test: cover empty results"
แต่ละ commit ควร build ผ่าน + test ผ่าน อ่านแค่ commit message ก็เข้าใจการเปลี่ยนแปลง
ขั้นที่ 3: เปิด Pull Request เร็ว
อย่ารอจนเสร็จแล้วค่อยเปิด PR — เปิดตั้งแต่เริ่มเป็น "Draft PR" คนอื่นเห็น code ระหว่างทาง comment ได้ก่อนเสร็จ
ขั้นที่ 4: merge ไว
PR ที่ merge ในวันเดียวหรือ 2 วัน conflict น้อยมาก feedback loop เร็ว ทีมขยับเร็ว
PR ที่นั่งดอง 2 อาทิตย์ — main เปลี่ยนไปเยอะ rebase แล้ว conflict, reviewer ไม่อยากอ่าน 50 ไฟล์ทีเดียว, นาน feedback
ขั้นที่ 5: ลบ branch หลัง merge
ตั้งใน GitHub Settings → "Automatically delete head branches" จะลบให้อัตโนมัติ
งานใหญ่ทำยังไงถ้าต้องเสร็จเป็นเดือน
ใช้ Feature Flag (เรียก feature toggle ก็ได้)
แทนที่จะแยก branch ยาวๆ — merge code เข้า main ตั้งแต่วันแรก แต่ซ่อนหลัง flag เปิดเฉพาะใน dev environment
// lib/features.ts
export const features = {
newCheckout: process.env.NEXT_PUBLIC_FF_NEW_CHECKOUT === 'true',
searchV2: process.env.NEXT_PUBLIC_FF_SEARCH_V2 === 'true',
}
// ใน component
import { features } from '@/lib/features'
export function CheckoutButton() {
if (features.newCheckout) {
return <NewCheckoutFlow />
}
return <LegacyCheckoutFlow />
}
ตอน dev — ตั้ง NEXT_PUBLIC_FF_NEW_CHECKOUT=true ใน .env.local
ตอน production — ค่อยตั้งค่าเปิด flag เมื่อพร้อม
วิธีนี้ทำให้:
- โค้ดใหม่อยู่ใน main ตลอด (ทดสอบ integration ได้)
- เปิด-ปิด feature ได้ใน production โดยไม่ต้อง deploy
- A/B test ได้ง่าย (แสดง flag = true ให้ user 10%)
ใช้ feature flag service เช่น Vercel Edge Config, LaunchDarkly, GrowthBook, Unleash จะดีขึ้นไปอีก เพราะเปลี่ยน flag ทันทีไม่ต้อง deploy
กฎพื้นฐานบน main
ใน GitHub: Settings → Branches → Add branch protection rule
ตั้งกฎกับ main:
- ✅ Require pull request before merging
- ✅ Require approvals — 1 หรือ 2 คน
- ✅ Require status checks to pass — เลือก CI workflow
- ✅ Require branches to be up to date before merging
- ✅ Include administrators (กันลืมเผลอ push เอง)
ผลลัพธ์: ไม่มีใคร push เข้า main ได้ตรงๆ ทุกการเปลี่ยนแปลงผ่าน PR + ผ่าน CI test เสมอ
Commit Message Convention
ทีมจะอ่าน history ง่ายขึ้นถ้ามี convention ใช้ Conventional Commits:
feat: เพิ่ม feature ใหม่
fix: แก้ bug
docs: แก้เอกสาร
style: formatting, lint (ไม่เปลี่ยน logic)
refactor: refactor code (ไม่ใช่ feat ไม่ใช่ fix)
perf: ปรับ performance
test: เพิ่ม/แก้ test
build: เปลี่ยนระบบ build / dependency
ci: เปลี่ยน config CI/CD
chore: งาน maintenance อื่นๆ
ตัวอย่าง:
feat(auth): add Google OAuth sign-in
- ใช้ next-auth v5
- เก็บ refresh token ใน database
- ทดสอบกับ Google account จริงแล้ว
Closes #142
ข้อดี: เครื่องมืออย่าง release-please สามารถสร้าง changelog + version bump อัตโนมัติจาก commit message
สรุป
Gitflow → Trunk-based ลด complexity เยอะ การที่ branch อยู่ไม่นาน + main protected + CI ที่แข็งแรง คือ formula ของทีมที่ deploy ได้บ่อยและมั่นใจ
ถ้าทีมอยู่ระหว่างเปลี่ยน เริ่มด้วยการตั้ง branch protection กับ main + บังคับ PR ก่อน ส่วน feature flag ค่อยๆ ใส่ตามความจำเป็น