Git Flow คือ Branching Strategy ยอดนิยมที่สร้างโดย Vincent Driessen ในปี 2010 มีโครงสร้าง branch ที่ชัดเจน ทำให้ทีมสามารถทำงานร่วมกันได้อย่างเป็นระบบ เหมาะสำหรับโปรเจกต์ที่มี release cycle ชัดเจน เช่น web app, mobile app หรือ software package บทความนี้จะอธิบายรายละเอียด Git Flow พร้อมตัวอย่างการใช้งาน เพื่อให้ทีมของคุณสามารถจัดการ code และ release ได้อย่างมีระเบียบ

โครงสร้าง Branch ใน Git Flow

Git Flow ใช้ branch หลัก 5 ประเภท ซึ่งแต่ละประเภทมีบทบาทเฉพาะในการพัฒนา:

1. main (master)

Branch สำหรับ Production เสมอ ทุก commit ใน main คือ version ที่ release แล้ว แต่ละ commit จะถูก tag ด้วย version number เช่น v1.0.0, v1.1.0 ควรมี protection rules เพื่อป้องกันการ push โดยตรง และต้องผ่าน pull request review ก่อน

2. develop

Branch หลักสำหรับการพัฒนา เป็น integration branch ที่ feature ใหม่ทุกอย่างจะ merge เข้ามาที่นี่ก่อน จากนั้นจึงสร้าง release branch เพื่อเตรียม production เป็นจุดสะสมของการพัฒนาล่าสุด

3. feature/*

Branch สำหรับพัฒนาฟีเจอร์ใหม่ แตกออกมาจาก develop และ merge กลับเข้า develop เมื่อพัฒนาเสร็จ ชื่อ branch ควรเป็นคำอธิบายฟีเจอร์ เช่น feature/user-authentication, feature/payment-integration

4. release/*

Branch สำหรับเตรียม release แตกออกจาก develop ใช้สำหรับ testing และแก้บั๊กเล็กน้อย ก่อน merge เข้า main และ develop ช่วยให้ develop branch ว่างไว้สำหรับพัฒนาฟีเจอร์ใหม่ขณะที่ทดสอบ release

5. hotfix/*

Branch สำหรับแก้บั๊กด่วนใน production แตกออกจาก main โดยตรง เมื่อแก้เสร็จจะ merge ทั้ง main และ develop เป็นเครื่องมือฉุกเฉินเมื่อพบปัญหาใน production ที่ไม่สามารถรอ release ปกติได้

ขั้นตอนการทำงานใน Git Flow

เริ่มต้น Project

# ติดตั้ง git-flow tool (macOS)
brew install git-flow-avh

# สำหรับ Ubuntu/Debian
sudo apt-get install git-flow

# เริ่มต้น Git Flow ใน project
git flow init

# จะถามชื่อ branch ต่างๆ กด Enter เพื่อใช้ค่าเริ่มต้น

เริ่ม Feature Branch

# สร้าง feature branch ใหม่
# git flow feature start <name>
git flow feature start user-authentication

# สิ่งที่จะเกิดขึ้น:
# - สร้าง branch feature/user-authentication จาก develop
# - สลับไปยัง branch นั้นอัตโนมัติ
# - พร้อมสำหรับ development

เสร็จ Feature และ Merge เข้า Develop

# เสร็จแล้วใช้คำสั่ง finish
git flow feature finish user-authentication

# สิ่งที่จะเกิดขึ้น:
# - Merge feature/user-authentication เข้า develop
# - ลบ feature/user-authentication branch
# - สลับไปยัง develop
# - หากมี conflict ต้องแก้ไขก่อน finish

สร้าง Release

# เริ่ม release branch
git flow release start 1.2.0

# แก้ไข version number ในไฟล์ต่างๆ
# ทำการ testing และแก้บั๊ก

# เมื่อ ready ให้ release
git flow release finish 1.2.0

# สิ่งที่จะเกิดขึ้น:
# - Merge release/1.2.0 เข้า main และ develop
# - Tag version 1.2.0 ใน main
# - ลบ release/1.2.0 branch

แก้บั๊กด่วน (Hotfix)

# เปิด hotfix จาก main
git flow hotfix start fix-login-crash

# แก้ไขบั๊ก เสร็จแล้ว
git flow hotfix finish fix-login-crash

# สิ่งที่จะเกิดขึ้น:
# - Merge hotfix/fix-login-crash เข้าทั้ง main และ develop
# - Tag version ใหม่ใน main (เพิ่ม patch number)
# - ลบ hotfix branch

ข้อดีและข้อเสียของ Git Flow

การใช้ Branch Protection Rules

เพื่อให้ Git Flow มีประสิทธิภาพสูง สำคัญที่จะต้องตั้งค่า protection rules บน main และ develop branch ใน GitHub หรือ GitLab ดังนี้:

• ต้องผ่าน code review อย่างน้อย 1-2 คน
• ต้องผ่าน automated tests (CI/CD)
• ห้าม force push
• ห้าม delete branch

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่า protection rules ดู วิธีตั้งค่า Branch Protection Rules ใน GitHub และ GitLab

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

สำหรับทีมที่ใช้ Continuous Deployment หรือต้องการความเรียบง่าย อาจพิจารณา GitHub Flow (มีแค่ main กับ feature branch) หรือ Trunk-Based Development (ทุกคนทำงานบน branch เดียว) แทน เพราะสิ่งเหล่านี้เน้นความเรียบง่ายและคื่นโค้ดสู่ production ได้เร็วกว่า

หากต้องการเปรียบเทียบอย่างละเอียด ดู GitHub Flow vs Git Flow vs Trunk-Based Development: เลือกเลยไหน?

Git Tag สำหรับการตั้งเวอร์ชัน

ในการใช้ Git Flow ที่มี release อย่างเป็นระบบ การใช้ Git Tag นั้นสำคัญมาก เพื่อระบุเวอร์ชันของแต่ละ release ได้ชัดเจน หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการสร้างและใช้งาน Git Tag ดู Git Tag คืออะไร? วิธีสร้าง Version Tag สำหรับ Release

Merge vs Rebase ใน Git Flow

เมื่อ merge feature branch กลับเข้า develop คำถามที่มักเกิดขึ้นคือ ควรใช้ merge หรือ rebase? สำหรับ Git Flow ปกติแนะนำให้ใช้ merge (ไม่ใช้ rebase) เพื่อรักษา history ที่ชัดเจน ดู Git Merge vs Rebase: เลือกใช้อันไหนดี? สำหรับข้อมูลเพิ่มเติม

สรุป

Git Flow เหมาะสำหรับทีมที่ต้องการความชัดเจนในการจัดการ release และโครงสร้างของมันเป็นรากฐานของทีม Developer สมัยใหม่หลายทีม การทำความเข้าใจ Git Flow อย่างลึกซึ้ง จะช่วยให้คุณเลือกใช้และปรับใช้ให้เหมาะสมกับโปรเจกต์ สามารถทำให้ workflow ของคุณเป็นระบบและประสิทธิภาพสูงสุด ในขณะเดียวกัน ผู้ให้บริการโฮสติ้ง Cloud VPS ของเรากำหนดขึ้นมาเพื่อสนับสนุน Git workflow ต่างๆ ให้ทีมพัฒนาสามารถจัดการ code repository ได้อย่างมีประสิทธิภาพ