Team 5 người, ai cũng push thẳng vào develop, conflict tứ tung, release dính feature chưa xong. Gitflow sinh ra để giải quyết đúng bài toán này: tách biệt rõ ràng code đang dev, code sẵn sàng release, và code trên production.

Gitflow là gì?#

Gitflow là một branching model — bộ quy tắc về cách tạo, đặt tên, merge branch trong team. Nó định nghĩa 5 loại branch với vai trò rõ ràng, giúp nhiều người dev song song mà không đạp lên nhau.

NOTE

Gitflow không phải tool bắt buộc. Bạn có thể dùng lệnh git flow (CLI tool) hoặc tự tạo branch theo convention — kết quả như nhau.

5 loại branch#

main (master)  ──●──────────────●──────────●──  (production)
                 │              ↑          ↑
                 │         release/v1.1  hotfix/fix-crash
                 │              ↑          │
develop        ──●──●──●──●────●──●────────●──  (integration)
                    │     │
                 feature/ feature/
                 login    payment

Branch cố định#

Quy tắc sống còn: Không ai commit trực tiếp vào main hoặc develop. Mọi thay đổi đều qua Pull Request.

Branch tạm thời#

Workflow thực tế#

1. Dev feature#

# Tạo branch từ develop
git checkout develop
git checkout -b feature/add-payment

# Code, commit thường xuyên
git add .
git commit -m "feat: add payment method selection"
git commit -m "feat: integrate Stripe API"

# Push và tạo Pull Request vào develop
git push -u origin feature/add-payment
# → Tạo PR trên GitHub/GitLab, chờ review

Sau khi PR được approve và merge → xóa branch feature/add-payment.

2. Tạo release#

Khi develop đã có đủ feature cho phiên bản tiếp theo:

# Tạo release branch từ develop
git checkout develop
git checkout -b release/v1.1.0

# Trên branch này CHỈ fix bug, update version, changelog
git commit -m "fix: validate empty email on checkout"
git commit -m "chore: bump version to 1.1.0"

# Merge vào main → deploy
git checkout main
git merge release/v1.1.0
git tag v1.1.0

# Merge ngược lại develop (để develop có bug fix)
git checkout develop
git merge release/v1.1.0

# Xóa release branch
git branch -d release/v1.1.0

TIP

Dùng git flow CLI thì chỉ cần git flow release finish v1.1.0 — nó tự merge cả 2 chiều và tạo tag.

3. Hotfix production#

User report lỗi crash trên production, không thể chờ release tiếp:

# Tạo hotfix từ main (code đang chạy production)
git checkout main
git checkout -b hotfix/fix-crash-on-login

# Fix và test
git commit -m "fix: null check on user session"

# Merge vào main → deploy ngay
git checkout main
git merge hotfix/fix-crash-on-login
git tag v1.1.1

# Merge vào develop (để develop cũng có fix)
git checkout develop
git merge hotfix/fix-crash-on-login

Convention#

Đặt tên branch#

feature/add-payment-method
feature/JIRA-123-user-profile
bugfix/fix-null-ref-checkout
release/v1.2.0
hotfix/fix-crash-on-login

Quy tắc: type/mô-tả-ngắn hoặc type/TICKET-ID-mô-tả.

Commit message#

Dùng Conventional Commits:

feat: add payment method selection
fix: resolve null reference on checkout
chore: update CI pipeline config
refactor: extract validation logic to service
docs: add API endpoint documentation

Lợi ích: changelog tự sinh, dễ trace lỗi, CI/CD có thể tự quyết định version bump.

Gitflow vs Trunk-Based Development#

Chọn Gitflow khi:

• Release theo sprint/cycle (2 tuần, hàng tháng)
• Cần QA riêng trước khi lên production
• Team từ 4-5 người trở lên dev song song
• Cần maintain nhiều version cùng lúc

Chọn Trunk-Based khi:

• Deploy liên tục (nhiều lần/ngày)
• Team nhỏ (2-3 người), communication tốt
• Có feature flags để kiểm soát release
• CI/CD pipeline mạnh, test coverage cao

Sai lầm phổ biến#

1. Feature branch sống quá lâu#

Branch tách ra 2-3 tuần không merge → conflict khổng lồ khi merge lại. Giải pháp: merge develop vào feature branch thường xuyên (ít nhất mỗi ngày), hoặc chia feature nhỏ hơn.

2. Fix bug trên release branch rồi quên merge về develop#

Release branch fix 5 bug, merge vào main xong quên merge về develop → sprint sau bug quay lại. Luôn merge release/hotfix vào cả main và develop.

3. Commit trực tiếp vào main/develop#

“Fix nhanh cái này thôi” → team không ai review → production lỗi. Cấu hình branch protection rules trên GitHub/GitLab để chặn push trực tiếp.

4. Không đặt tên branch theo convention#

my-branch, test123, fix → 3 tháng sau không ai biết branch này làm gì. Luôn dùng format type/mô-tả.

Checklist cho team#

• Cấu hình branch protection cho main và develop (require PR, require review)
• Thống nhất naming convention (branch + commit message)
• CI/CD pipeline chạy trên mọi PR (lint, test, build)
• Tối thiểu 2 reviewer trước khi merge
• Merge develop vào feature branch ít nhất mỗi ngày
• Xóa branch sau khi merge

Tổng kết#

Gitflow không phải silver bullet — nó thêm overhead so với trunk-based. Nhưng với team từ 4-5 người, có release cycle rõ ràng, và cần QA trước khi deploy, Gitflow giữ cho codebase có trật tự.

Nắm 3 thứ: 5 loại branch và quy tắc merge, convention đặt tên, và merge thường xuyên để tránh conflict khổng lồ. Phần còn lại là kỷ luật team.