info-gitflow-branching-strategy

การทำงานร่วมกันด้วย Git ไม่ได้มีเพียงการสร้าง branch แล้ว merge กลับเข้า main เท่านั้น แต่ในงานจริงทีมพัฒนามักกำหนด Branching Strategy หรือ Git Workflow เพื่อควบคุมว่าแต่ละ branch ใช้ทำอะไร ใครเป็นผู้ merge งาน และเมื่อใดจึงสามารถนำโค้ดขึ้น Production ได้

คำว่า GitFlow มักถูกใช้ใน 2 ความหมาย คือ

  1. Git Flow แบบดั้งเดิม ที่มี main, develop, feature, release และ hotfix
  2. ใช้เรียกรวม ๆ ถึงแนวทางจัดการ branch เช่น GitHub Flow, GitLab Flow หรือ Trunk-Based Development

บทความนี้สรุปรูปแบบที่นิยม พร้อมข้อดี ข้อจำกัด และแนวทางเลือกใช้ในโครงการจริง

#1. Original Git Flow

Git Flow แบบดั้งเดิมเหมาะกับระบบที่มี รอบการออกเวอร์ชันชัดเจน และต้องควบคุม Release อย่างเป็นทางการ

Branch หลักประกอบด้วย

  • main — โค้ดที่พร้อมใช้งาน Production
  • develop — โค้ดสำหรับการพัฒนารุ่นถัดไป
  • feature/* — พัฒนาคุณสมบัติใหม่
  • release/* — เตรียม Release
  • hotfix/* — แก้ปัญหาเร่งด่วนบน Production
gitGraph
    commit id: "v1.0"
    branch develop
    commit id: "develop"
    branch feature/login
    commit id: "login-1"
    commit id: "login-2"
    checkout develop
    merge feature/login
    branch release/1.1
    commit id: "prepare release"
    checkout main
    merge release/1.1 tag: "v1.1"
    checkout develop
    merge release/1.1

#ตัวอย่างการสร้าง Feature

git checkout develop
git pull

git checkout -b feature/login

git add .
git commit -m "feat: add login page"

git checkout develop
git merge feature/login

#ตัวอย่าง Hotfix

git checkout main
git checkout -b hotfix/fix-payment

# แก้ไขโค้ด

git add .
git commit -m "fix: payment validation"

git checkout main
git merge hotfix/fix-payment

git checkout develop
git merge hotfix/fix-payment

#เหมาะกับ

  • Enterprise Application
  • ระบบที่มี Release Cycle เช่น v1.0, v1.1, v2.0
  • ทีมที่มี QA/UAT ก่อน Production
  • ระบบที่ต้องดูแลหลายเวอร์ชันพร้อมกัน

#ข้อจำกัด

  • Branch จำนวนมาก
  • Merge หลายขั้นตอน
  • Conflict เกิดได้ง่ายถ้า branch อยู่เป็นเวลานาน
  • ไม่คล่องตัวนักสำหรับ Continuous Deployment

#2. GitHub Flow

GitHub Flow เป็นรูปแบบที่ง่ายกว่า Git Flow โดยมี main เป็น branch หลัก และสร้าง Feature Branch ระยะสั้น

โครงสร้างพื้นฐานคือ

main
 └── feature/login
 └── feature/payment
 └── fix/navbar

Workflow ทั่วไป

Create Branch
      ↓
Develop
      ↓
Commit / Push
      ↓
Pull Request
      ↓
Review + CI
      ↓
Merge to main
      ↓
Deploy

#ตัวอย่าง

git checkout main
git pull

git checkout -b feature/profile

git add .
git commit -m "feat: add user profile"

git push origin feature/profile

จากนั้นสร้าง Pull Request และ merge กลับเข้า main

#เหมาะกับ

  • Web Application
  • SaaS
  • ทีม Agile
  • Continuous Integration
  • Continuous Delivery / Continuous Deployment

#จุดเด่น

  • เข้าใจง่าย
  • Branch น้อย
  • ทำงานร่วมกับ Pull Request ได้ดี
  • เหมาะกับระบบ CI/CD

#3. GitLab Flow

GitLab Flow เป็นแนวทางที่ผสมข้อดีของ Git Flow + GitHub Flow และสามารถเพิ่ม branch ตาม Environment หรือ Release ได้

ตัวอย่าง

feature/*
    ↓
main
    ↓
staging
    ↓
production

หรือ

feature/*
    ↓
main
    ↓
release/*

ตัวอย่าง Environment Branch

main
 ↓
staging
 ↓
production

#เหมาะกับ

  • ระบบที่มีหลาย Environment
  • Dev / QA / Staging / Production
  • องค์กรที่มี Approval Process
  • DevOps Pipeline ที่ต้องควบคุม Deployment

#ข้อดี

  • ยืดหยุ่น
  • Mapping branch กับ Environment ได้ง่าย
  • เหมาะกับ CI/CD Pipeline แบบหลายขั้นตอน

#4. Trunk-Based Development

Trunk-Based Development หรือ TBD ใช้ branch หลักเพียง branch เดียว เช่น main หรือ trunk

Developer สร้าง Feature Branch ที่มีอายุสั้นมาก แล้ว merge กลับเข้าสู่ trunk อย่างรวดเร็ว

       feature-a
      /        \
main ----------●----------
        feature-b
       /      \
------●--------●-----------

หลักสำคัญคือ

  • Merge บ่อย
  • Feature Branch ต้องสั้น
  • CI ต้องทำงานเร็ว
  • Automated Test ต้องมีประสิทธิภาพ
  • ใช้ Feature Flag สำหรับฟีเจอร์ที่ยังไม่พร้อมเปิดใช้งาน

#ตัวอย่าง

git checkout main
git pull

git checkout -b feature/search

# พัฒนา feature

git add .
git commit -m "feat: search"

git push origin feature/search

จากนั้นสร้าง Pull Request แล้ว merge กลับ main ภายในระยะเวลาสั้น

#เหมาะกับ

  • ทีม DevOps ที่มี maturity สูง
  • Continuous Integration
  • Continuous Deployment
  • Microservices
  • ทีมที่มี Automated Test ครอบคลุมดี

#ข้อดี

  • ลด Merge Conflict
  • Integration เร็ว
  • Feedback เร็ว
  • เหมาะกับการ Deploy หลายครั้งต่อวัน

#5. Release Flow

Release Flow มักใช้กับผลิตภัณฑ์ที่มี main เป็นแหล่งหลักของการพัฒนา แต่เมื่อถึงช่วง Release จะสร้าง branch สำหรับรุ่นนั้น

ตัวอย่าง

main ────────────────●───────────────●────>
                     \
                      release/2.0 ───●───>

Feature จะ merge เข้า main ตามปกติ ส่วน Release Branch ใช้สำหรับ

  • Bug Fix ก่อนปล่อยเวอร์ชัน
  • Stabilization
  • Patch
  • Version-specific maintenance

#เหมาะกับ

  • Product ขนาดใหญ่
  • Desktop Software
  • Library / Framework
  • ระบบที่ต้องรองรับหลาย Release

#6. Environment-Based Branching

บางองค์กรกำหนด branch ตาม Environment โดยตรง เช่น

development
     ↓
staging
     ↓
production

ตัวอย่าง CI/CD

feature/*
    ↓
development
    ↓
staging
    ↓
production

Pipeline อาจกำหนดว่า

development -> Deploy Dev
staging     -> Deploy Staging
production  -> Deploy Production

#เหมาะกับ

  • ระบบที่มีหลาย Environment
  • ทีมที่ต้องการ Manual Approval ก่อน Production
  • ระบบที่มี Dev / SIT / UAT / Production

#ข้อควรระวัง

การใช้ branch แทน Environment มากเกินไปอาจทำให้เกิด

  • Branch Drift
  • Merge Conflict
  • โค้ดในแต่ละ Environment ไม่ตรงกัน
  • Cherry-pick ซ้ำซ้อน

จึงควรใช้ร่วมกับ CI/CD และกำหนด Promotion Process ให้ชัดเจน

#เปรียบเทียบ Git Workflow

Workflow Branch Complexity Release Control CI/CD เหมาะกับ
Git Flow สูง สูงมาก ปานกลาง Enterprise / Versioned Release
GitHub Flow ต่ำ ปานกลาง สูง Web / SaaS
GitLab Flow ปานกลาง สูง สูง Multi-Environment
Trunk-Based ต่ำมาก ผ่าน CI/CD สูงมาก DevOps / Continuous Delivery
Release Flow ปานกลาง สูง สูง Product / Multiple Versions
Environment-Based ปานกลาง-สูง สูง สูง Dev / QA / Staging / Prod

#Hybrid Git Flow

ในงานจริงองค์กรจำนวนมากไม่ได้ใช้แนวทางใดแนวทางหนึ่งแบบ 100% แต่สร้าง Hybrid Workflow

ตัวอย่าง

main
 ↑
develop
 ↑
feature/*

แต่เพิ่ม Pull Request + CI

feature/*
   ↓
Pull Request
   ↓
CI Test
   ↓
Code Review
   ↓
develop

เมื่อ Release

develop
   ↓
release/*
   ↓
main

แนวทางนี้คือการนำโครงสร้าง Git Flow มารวมกับวิธี Review แบบ GitHub Flow

#ตัวอย่าง Branch Naming Convention

ควรกำหนดชื่อ branch ให้เป็นมาตรฐาน

feature/login
feature/payment
feature/user-profile

fix/navbar
fix/login-error

hotfix/payment-timeout

release/1.0.0
release/1.1.0

หากใช้ Issue Tracking

feature/PROJ-101-login
fix/PROJ-205-payment

#Conventional Commit ที่ใช้ร่วมกับ Git Workflow

ตัวอย่าง

git commit -m "feat: add login API"
git commit -m "fix: correct JWT validation"
git commit -m "docs: update API documentation"
git commit -m "test: add login integration test"
git commit -m "refactor: simplify user service"

ประเภทที่นิยม

feat
fix
docs
test
refactor
perf
build
ci
chore

#การใช้งานร่วมกับ CI/CD

Branch Strategy ควรถูกเชื่อมกับ Pipeline

ตัวอย่าง

feature/*
   ↓
Unit Test
Lint
Security Scan

main
   ↓
Build
Integration Test
Container Image
Deploy Staging

tag v1.x
   ↓
Deploy Production

ตัวอย่าง GitHub Actions

name: CI

on:
  push:
    branches:
      - main
      - develop
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run tests
        run: npm test

#Branch Protection ที่ควรใช้

สำหรับ main หรือ production ควรกำหนด

  • ห้าม Push โดยตรง
  • ต้อง Merge ผ่าน Pull Request
  • ต้องผ่าน Automated Test
  • ต้องผ่าน Code Review
  • Require Status Checks
  • Require Approval
  • ป้องกัน Force Push
  • ป้องกันการลบ branch

ตัวอย่าง Workflow

Developer
   ↓
Feature Branch
   ↓
Pull Request
   ↓
CI Test
   ↓
Code Review
   ↓
Merge
   ↓
Deployment

#แนวทางเลือกใช้

#ทีมเล็ก / Web Application

แนะนำ

GitHub Flow

โครงสร้าง

main
 └── feature/*

#ทีม DevOps / Continuous Deployment

แนะนำ

Trunk-Based Development

ร่วมกับ

  • CI/CD
  • Automated Test
  • Feature Flag
  • Code Review

#Enterprise Application

แนะนำ

Git Flow

หรือ

GitLab Flow

โดยเฉพาะเมื่อมี

Development
QA
UAT
Staging
Production

#Product ที่มีหลาย Version

แนะนำ

Release Flow

เช่น

main
release/1.x
release/2.x

#ตัวอย่าง Git Flow สำหรับโครงการจริง

                         ┌──────── feature/login
                         │
develop ─────●───────────●────────────●──────────────
             │                         │
             │                         └── release/1.1
             │                                  │
main ────────●──────────────────────────────────●─────
                                                  │
                                             tag v1.1

หาก Production มี Bug

main
 │
 └── hotfix/payment
          │
          ├── merge -> main
          │
          └── merge -> develop

#สรุป

ไม่มี Git Workflow แบบใดที่ดีที่สุดสำหรับทุกโครงการ การเลือกรูปแบบควรพิจารณาจาก

  • จำนวนสมาชิกในทีม
  • ความถี่ของการ Release
  • จำนวน Environment
  • ระดับ Automation ของ CI/CD
  • Automated Testing
  • ความต้องการ Code Review
  • ความซับซ้อนของระบบ
  • จำนวนเวอร์ชันที่ต้องดูแลพร้อมกัน

คำแนะนำโดยย่อคือ

ทีมเล็ก / Web App
→ GitHub Flow

ทีม DevOps / Deploy บ่อย
→ Trunk-Based Development

Enterprise / Release เป็นรอบ
→ Git Flow

หลาย Environment
→ GitLab Flow

หลาย Product Version
→ Release Flow

สำหรับทีมสมัยใหม่ที่มี CI/CD และ Automated Test ที่ดี ควรพยายาม ลดอายุของ branch ให้สั้น, merge บ่อย และใช้ Pull Request + Automated Checks เพื่อให้ Integration เกิดขึ้นอย่างต่อเนื่อง