Git Branching Workflow — Feature Branch, Trunk-Based, GitFlow

ทำไมต้องมี Branching Strategy

การทำงานคนเดียวบน main อาจพอ แต่พอมีหลายคน:

• โค้ดชนกัน (conflicts) บ่อย
• feature ที่ยังไม่เสร็จโดน deploy ไปด้วย
• ไม่รู้ว่า commit ไหนทำให้ production พัง

Branching strategy แก้ปัญหาเหล่านี้โดยกำหนดว่า branch มีความหมายอะไรและ flow เป็นยังไง

1. Feature Branch Workflow

Pattern ที่ใช้บ่อยที่สุด — งานทุกชิ้นอยู่บน branch ของตัวเอง:

main ──●──────────────────────●── (release)
        \                    /
feature  ●──●──●──●──●──●──●

# เริ่มงาน
git checkout main && git pull
git checkout -b feature/user-auth

# ทำงาน commit ปกติ
git add .
git commit -m "feat: add login form validation"

# sync กับ main ถ้า main เดินไปข้างหน้า
git fetch origin
git rebase origin/main

# merge กลับ main
git checkout main
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

เหมาะกับ: ทีมขนาดกลาง, ต้องการ code review ก่อน merge

ข้อเสีย: feature ที่ใช้เวลานานจะ diverge มากจาก main — rebase/merge ยาก

2. Trunk-Based Development

ทุกคน commit ลง main (trunk) บ่อยๆ — branch สั้นมาก (< 1 วัน) หรือ commit ตรง:

main ──●──●──●──●──●──●──●──●──

# ถ้าต้องการ branch สั้นๆ
git checkout -b fix/typo-in-login
# ทำงาน ทดสอบ
git commit -m "fix: correct typo in login error message"
git checkout main
git merge fix/typo-in-login
git push

# Feature ใหญ่ใช้ Feature Flags แทน branching ยาว

เหมาะกับ: CI/CD ที่แน่น, ทีมที่มี test coverage ดี, deploy บ่อยๆ

ต้องมี: Feature flags, test suite แน่น, deploy pipeline อัตโนมัติ

3. Gitflow

Pattern ที่ structured มากที่สุด — มีหลาย branch type:

main     ──●──────────────────────────●── v1.0.0
            \                        /
release      ●──●──●────────────────●
              \  \                 /
develop   ──●──●──●──●──●──●──●──●──
                   \         /
feature             ●──●──●

# เริ่ม feature
git checkout develop
git checkout -b feature/payment-gateway

# เสร็จ merge กลับ develop
git checkout develop
git merge --no-ff feature/payment-gateway

# เตรียม release
git checkout -b release/1.2.0

# ออก release
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Version 1.2.0"

git checkout develop
git merge --no-ff release/1.2.0

เหมาะกับ: software ที่มีหลาย version ออกมา, mobile apps, libraries

ข้อเสีย: ซับซ้อน merge เยอะ ไม่เหมาะกับ continuous deployment

Command ที่ใช้บ่อยในทุก Workflow

# ดู branch ทั้งหมด
git branch -a

# สร้างและ checkout ทันที
git checkout -b feature/my-feature
# หรือ (git >= 2.23)
git switch -c feature/my-feature

# ลบ branch local
git branch -d feature/my-feature    # ถ้า merged
git branch -D feature/my-feature    # force delete

# ลบ branch remote
git push origin --delete feature/my-feature

# ดู merge status
git branch --merged main
git branch --no-merged main

# Rebase กับ main (แทน merge สำหรับ feature branches)
git rebase origin/main
# ถ้าชนกัน
git add .
git rebase --continue
# หรือยกเลิก
git rebase --abort

Merge vs Rebase

Merge:
main    ──●──────────●──── (merge commit)
           \        /
feature     ●──●──●

Rebase:
main    ──●──●──●──● (feature commits อยู่ต่อจาก main)

# Merge — สร้าง merge commit, preserve history
git merge feature/my-feature

# Merge --no-ff — บังคับสร้าง merge commit แม้ fast-forward ได้
git merge --no-ff feature/my-feature

# Rebase — เขียน history ใหม่ให้ดูเป็นเส้นตรง
git rebase main

กฎทอง: ห้าม rebase branch ที่ share กับคนอื่น (เช่น main, develop)

Stash — เก็บงานชั่วคราว

# เก็บ uncommitted changes
git stash push -m "WIP: login validation"

# ดูรายการ
git stash list

# คืนงาน
git stash pop          # คืน stash ล่าสุด + ลบออกจาก list
git stash apply stash@{0}  # คืน stash ที่เลือก + ยังอยู่ใน list

# ลบทิ้ง
git stash drop stash@{0}
git stash clear  # ล้างทั้งหมด

Tag สำหรับ Release

# สร้าง annotated tag
git tag -a v1.0.0 -m "First stable release"

# push tag
git push origin v1.0.0
git push origin --tags  # push ทุก tag

# ดู tags
git tag -l "v1.*"

# ลบ tag
git tag -d v1.0.0
git push origin --delete v1.0.0

เลือก Workflow ยังไง

สิ่งสำคัญกว่า workflow คือความสม่ำเสมอ — ทีมที่ทำตาม workflow เดียวกันสม่ำเสมอดีกว่าทีมที่เลือก workflow “ถูก” แต่ทำตามบ้างไม่ทำตามบ้าง