Git Flow: คืออะไร โมเดลการแตกกิ่ง และการใช้งานในโปรเจกต์

Git Flow คืออะไร?

Git Flow — โมเดลการแตกกิ่ง Git ที่กำหนดโครงสร้างกิ่งและกฎการรวมที่เข้มงวดสำหรับจัดการการพัฒนา การเผยแพร่ และการแก้ไข Vincent Driessen เผยแพร่บทความ “A successful Git branching model” ในเดือนมกราคม 2010 และตั้งแต่นั้นมา Git Flow ได้กลายเป็นมาตรฐานโดยพฤตินัยในการพัฒนา Java และ .NET ระดับองค์กร แนวคิดหลัก — การแบ่งโค้ดออกเป็นห้าประเภทกิ่งที่มีระดับความเสถียรแตกต่างกัน

ตามข้อมูลจาก Atlassian Git Tutorials, 2024, Git Flow ขึ้นอยู่กับสองกิ่งถาวร: main (เดิมคือ master) และ develop กิ่งอื่นๆ ทั้งหมดเป็นกิ่งชั่วคราว: feature, release, hotfix แต่ละประเภทกิ่งมีวงจรชีวิตและกฎการรวมที่กำหนดไว้อย่างชัดเจน ในการพัฒนาแอปมือถือ Git Flow ใช้ในโปรเจกต์ที่มีรอบการเผยแพร่ปกติ (2–4 สัปดาห์) และรองรับหลายเวอร์ชัน

Git Flow แตกต่างจากโมเดลที่เรียบง่ายกว่า (GitHub Flow) ตรงที่ต้องมีกิ่ง develop แยกต่างหากสำหรับการรวม ซึ่งเพิ่มหนึ่งขั้นตอนในกระบวนการรวม แต่ให้การแยกคุณสมบัติที่ยังไม่เสร็จสมบูรณ์ออกจากโค้ดที่พร้อมเผยแพร่

Vincent Driessen และประวัติของ Git Flow

ในปี 2010 Vincent Driessen เผยแพร่โพสต์ “A successful Git branching model” ซึ่งกลายเป็นหนึ่งในโพสต์ที่ถูกอ้างอิงมากที่สุดในประวัติศาสตร์ Git โมเดลนี้ถูกสร้างขึ้นสำหรับโปรเจกต์ที่มีการเผยแพร่แบบกำหนดเวลาและการรองรับเวอร์ชันแบบขนาน ในปี 2020 Driessen ยอมรับว่า Git Flow ล้าสมัยสำหรับแนวทาง CI/CD สมัยใหม่ แต่โมเดลนี้ยังคงเกี่ยวข้องสำหรับโปรเจกต์ที่มีรอบการเผยแพร่ยาวและความจำเป็นในการรองรับเวอร์ชันเก่า

# การเริ่มต้นใช้งาน Git Flow
git flow init

# การสร้างกิ่ง feature
git flow feature start "add-auth"

# การเสร็จสิ้นกิ่ง feature (รวมเข้า develop)
git flow feature finish "add-auth"

# การสร้าง release
git flow release start "1.2.0"
git flow release finish "1.2.0"

กิ่ง Main: โค้ดเผยแพร่และการติดแท็ก

Main (เดิมคือ master) — กิ่งหลักที่เก็บเฉพาะโค้ดที่พร้อมเผยแพร่ ทุก commit ใน main ควรตรงกับเวอร์ชันเฉพาะของผลิตภัณฑ์ที่ถูกแท็ก (tag) ในรูปแบบ Semantic Versioning เช่น v1.0.0, v1.1.0 ไม่มีการพัฒนาโดยตรงใน main — การเปลี่ยนแปลงมาที่นี่ผ่านกิ่ง release หรือ hotfix เท่านั้น

ตามข้อมูลจาก semver.org, 2024, แท็กใน main ใช้รูปแบบ MAJOR.MINOR.PATCH MAJOR เพิ่มขึ้นเมื่อมีการเปลี่ยนแปลง API ที่ไม่เข้ากันได้ MINOR — เมื่อเพิ่มฟังก์ชันที่มีความเข้ากันได้ย้อนหลัง PATCH — เมื่อแก้ไขบั๊ก ใน Git Flow ทุก finish release จะสร้าง commit ใน main โดยอัตโนมัติพร้อมแท็กเวอร์ชัน

Main — กิ่งเดียวที่ถูกเผยแพร่สู่โปรดักชัน สำหรับโปรเจกต์มือถือ หมายความว่าเมื่อ push ไปที่ main จะเริ่มไปป์ไลน์การสร้าง App Bundle หรือ IPA และเผยแพร่สู่ Google Play / App Store ในการตั้งค่า CI/CD ของ GitLab main ถูกป้องกันจากการ force-push และการลบ

Semantic Versioning และแท็ก

ทุก commit ใน main มาพร้อมกับ แท็ก ในรูปแบบ SemVer: vMAJOR.MINOR.PATCH MAJOR — สำหรับการเปลี่ยนแปลง API ที่ไม่เข้ากันได้ MINOR — สำหรับฟังก์ชันใหม่ที่เข้ากันได้ย้อนหลัง PATCH — สำหรับการแก้ไขบั๊ก ตัวอย่าง: v2.1.0 หมายถึงการเผยแพร่เมเจอร์ครั้งที่สองพร้อมคุณสมบัติใหม่และไม่มีการแก้ไขบั๊ก ใน Git Flow แท็กถูกสร้างโดยอัตโนมัติเมื่อ finish release หรือ hotfix ผ่านคำสั่ง git flow release finish

กิ่ง Develop: แนวการพัฒนารวม

Develop — กิ่งถาวรที่สองของ Git Flow สำหรับรวมคุณสมบัติที่เสร็จสมบูรณ์ทั้งหมด นักพัฒนารวมกิ่ง feature เข้าไปยัง develop หลังจากผ่านการตรวจสอบโค้ดและการตรวจสอบ CI/CD Develop เก็บโค้ดเวอร์ชันเสถียรล่าสุดที่มีคุณสมบัติทั้งหมดที่ถูกนำไปใช้ในสปรินต์ปัจจุบัน

ตามข้อมูลจาก DataSift Git Flow Guide, 2024, develop อาจไม่เสถียรชั่วคราวเนื่องจากการรวมที่ยังไม่เสร็จสมบูรณ์ เพื่อป้องกันปัญหา ทีมงานปฏิบัติตาม Continuous Integration (CI): แต่ละคุณสมบัติผ่านชุดทดสอบที่สมบูรณ์ก่อนรวมเข้า develop ถ้า CI ล้มเหลว — นักพัฒนาแก้ไขโค้ดก่อนการรวมครั้งถัดไป Develop เชื่อมโยงกับเวอร์ชันปัจจุบันของ main เสมอ: ทันทีหลังการเผยแพร่ develop จะซิงโครไนซ์กับ main ผ่านการรวม

กิ่ง Feature: การพัฒนาฟังก์ชันใหม่

กิ่ง Feature — กิ่งชั่วคราวสำหรับพัฒนาคุณสมบัติเฉพาะ การแก้ไขบั๊ก หรือการทดลอง แต่ละกิ่ง feature ถูกสร้างจาก develop และหลังจากเสร็จสมบูรณ์จะถูกรวมกลับไปยัง develop ชื่อของกิ่ง feature มักประกอบด้วยหมายเลขงานหรือคำอธิบายสั้น: feature/APP-123-add-oauth, feature/redesign-profile ใน Git Flow กิ่ง feature สามารถมีอายุไม่จำกัด

ตามข้อมูลจาก Pro Git Book, 2024, กิ่ง feature เป็นสภาพแวดล้อมการพัฒนาแบบแยกส่วน: การเปลี่ยนแปลงในกิ่งหนึ่งไม่ส่งผลกระทบต่อกิ่งอื่นจนกว่าจะถึงเวลารวม ในโปรเจกต์มือถือ กิ่ง feature จะซิงโครไนซ์กับ develop ผ่าน rebase หรือ merge เพื่อหลีกเลี่ยงความขัดแย้งขนาดใหญ่เมื่อ finish แนะนำให้ rebase กิ่ง feature บน develop ก่อนสร้าง MR

# การสร้างกิ่ง feature ด้วยตนเอง (โดยไม่ใช้ git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# การสร้าง MR ใน GitLab ผ่าน CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

กิ่ง Release: การเตรียมการเผยแพร่

กิ่ง Release — กิ่งชั่วคราวที่สร้างจาก develop เพื่อเตรียมการเผยแพร่ เมื่อ develop มีชุดคุณสมบัติเพียงพอสำหรับเวอร์ชันใหม่ ทีมงานสร้างกิ่ง release/X.Y.Z (เช่น release/2.1.0) ในกิ่งนี้จะมีการแก้ไขเฉพาะขั้นสุดท้าย: การเพิ่มเวอร์ชัน การอัปเดตการแปลภาษา การทดสอบขั้นสุดท้าย การแก้ไขบั๊กที่สำคัญ

ตามข้อมูลจาก Atlassian Git Tutorials, 2024, กิ่ง release แก้ปัญหาสำคัญ: การแยกการแก้ไขขั้นสุดท้ายออกจากการพัฒนาแบบขนาน ในขณะที่ release กำลังเตรียมพร้อมสำหรับการออกสู่โปรดักชัน คุณสมบัติใหม่สำหรับการเผยแพร่ครั้งต่อไปยังคงถูกรวมเข้า develop หลังจากเสร็จสมบูรณ์ กิ่ง release จะถูกรวมเข้า main (พร้อมแท็ก) และเข้า develop (เพื่อซิงโครไนซ์การเพิ่มเวอร์ชัน)

กิ่ง Hotfix: การแก้ไขด่วนในโปรดักชัน

กิ่ง Hotfix — กิ่งชั่วคราวสำหรับแก้ไขบั๊กวิกฤตในโปรดักชันอย่างเร่งด่วน กิ่งประเภทเดียวใน Git Flow ที่สร้างจาก main แทนที่จะเป็น develop รูปแบบชื่อ: hotfix/X.Y.Z+1 (เช่น hotfix/2.1.1) หลังจากเสร็จสมบูรณ์ กิ่ง hotfix จะถูกรวมเข้าทั้ง main (เป็นการเผยแพร่แพทช์ใหม่) และ develop (เพื่อไม่ให้การแก้ไขสูญหายในการเผยแพร่ครั้งถัดไป)

ตามข้อมูลจาก DataSift Git Flow Guide, 2024, กิ่ง hotfix ควรสั้นที่สุดเท่าที่จะเป็นไปได้ — เฉพาะการแก้ไขและทดสอบ Hotfix ไม่ควรรวมคุณสมบัติใหม่หรือการปรับโครงสร้าง ในการพัฒนาแอปมือถือ hotfix ใช้สำหรับแก้ไขการคริติคอล (อัตราการคริช > 0.1%), ช่องโหว่ด้านความปลอดภัย หรือบั๊กที่บล็อกใน App Store

ข้อดีและข้อเสียของ Git Flow สำหรับการพัฒนาแอปมือถือ

Git Flow ให้โครงสร้างที่ชัดเจน ซึ่งมีประโยชน์โดยเฉพาะสำหรับทีมขนาดใหญ่และโปรเจกต์ที่มีการเผยแพร่เป็นประจำ ข้อดี: การแยกคุณสมบัติที่ยังไม่เสร็จในกิ่ง feature ความสามารถในการเตรียมการเผยแพร่โดยไม่บล็อกการพัฒนา การรองรับหลายเวอร์ชันผ่าน hotfix ข้อเสีย: ความซับซ้อนสำหรับผู้เริ่มต้น ความจำเป็นในการ rebase กิ่ง feature เป็นประจำ ความขัดแย้งในกิ่งที่มีอายุยาวนาน

ตามข้อมูลจาก Martin Fowler, 2024, ข้อเสียหลักของ Git Flow คือกิ่ง feature ที่มีอายุยาวนาน ถ้าคุณสมบัติถูกพัฒนา 2+ สัปดาห์โดยไม่ซิงโครไนซ์กับ develop ความขัดแย้งเมื่อรวมจะมีความสำคัญ สำหรับโปรเจกต์มือถือ แนะนำให้ซิงโครไนซ์กิ่ง feature ทุกวันผ่าน rebase บน develop

Git Flow ไม่แนะนำสำหรับโปรเจกต์ที่มี Continuous Deployment (ทุก commit ใน main → ไปยังโปรดักชัน) สำหรับโปรเจกต์ดังกล่าว GitHub Flow หรือ Trunk-Based Development ให้โมเดลที่ง่ายและเร็วกว่า แต่สำหรับโปรเจกต์ที่มีรอบการเผยแพร่และการรองรับเวอร์ชันเก่า Git Flow ยังคงเป็นตัวเลือกที่เหมาะสมที่สุด

เมื่อใดที่ Git Flow เป็นปัญหาสำหรับทีม

Git Flow กลายเป็น ปัญหา ในสามกรณี: ทีมมีน้อยกว่า 5 คน (ความซับซ้อนเกินไป), มี Continuous Deployment (ความล่าช้าในการส่งมอบ), ขาดวินัยในการ rebase (กิ่ง feature ที่มีอายุยาวนานสร้างความขัดแย้งในการ merge) ถ้าทีมใช้เวลามากกว่า 20% ในการรวมกิ่งและการแก้ไขความขัดแย้ง — Git Flow ไม่เหมาะกับทีมนั้นแม้ว่าจะมีขนาดใหญ่

ทางเลือกของ Git Flow: GitHub Flow และ Trunk-Based Development

ทางเลือกของ Git Flow เสนอกระบวนการที่ง่ายกว่าสำหรับทีมที่ปฏิบัติตาม CI/CD GitHub Flow ใช้เพียงกิ่งถาวรเดียว (main) และกิ่ง feature แต่ละคุณสมบัติถูกสร้างจาก main หลังจากการตรวจสอบและ CI จะถูกรวมกลับไปยัง main และเผยแพร่ทันที GitHub Flow ง่ายกว่า แต่ไม่รองรับการแยกคุณสมบัติที่ยังไม่เสร็จและการเตรียมการเผยแพร่แบบขนาน

ตามข้อมูลจาก GitHub Docs, 2024, Trunk-Based Development (TBD) ไปไกลกว่านั้นอีก: นักพัฒนาทุกคนทำงานในกิ่งเดียว (trunk) โดยใช้กิ่ง feature อายุสั้น 1–2 วัน Feature toggles (ธงคุณสมบัติ) ควบคุมการมองเห็นของโค้ดที่ยังไม่เสร็จ TBD ต้องมีวินัยสูงใน CI/CD และระบบอัตโนมัติในการทดสอบ

• GitHub Flow — หนึ่ง main + กิ่ง feature เหมาะสำหรับ CI/CD และทีมขนาดเล็ก
• GitLab Flow — พัฒนา Git Flow ด้วยกิ่งสภาพแวดล้อม (staging, production)
• Trunk-Based Development — หนึ่งกิ่ง + feature toggles, CI/CD สูงสุด, การรวมน้อยที่สุด
• One Flow — Git Flow ที่เรียบง่ายโดยไม่มีกิ่ง develop, เฉพาะ main + feature + release