Trunk-Based Development vs Git Flow: Chọn đúng Chiến lược Branching cho Team 2026

Posted on: 4/21/2026 1:15:07 PM

Chiến lược branching quyết định tốc độ ship code, chất lượng review, và khả năng rollback của team. Chọn sai mô hình Git có thể biến CI/CD pipeline thành nơi merge conflict chồng chất, release bị block hàng tuần, và developer mất thời gian resolve xung đột thay vì viết feature mới.

Bài viết này phân tích sâu hai mô hình phổ biến nhất — Git Flow và Trunk-Based Development (TBD) — kèm theo GitHub Flow, GitLab Flow, và dữ liệu từ DORA Research 2025–2026 để giúp bạn đưa ra quyết định phù hợp cho team mình.

Git Flow là gì?

Git Flow được Vincent Driessen giới thiệu năm 2010, nhanh chóng trở thành mô hình branching phổ biến nhất. Nó định nghĩa rõ ràng vai trò của từng nhánh trong vòng đời phát triển phần mềm.

gitGraph
    commit id: "init"
    branch develop
    checkout develop
    commit id: "setup"
    branch feature/login
    checkout feature/login
    commit id: "login-ui"
    commit id: "login-api"
    checkout develop
    merge feature/login id: "merge-login"
    branch release/1.0
    checkout release/1.0
    commit id: "bump-version"
    commit id: "fix-typo"
    checkout main
    merge release/1.0 id: "v1.0" tag: "v1.0"
    checkout develop
    merge release/1.0 id: "sync-develop"
    checkout main
    branch hotfix/1.0.1
    commit id: "critical-fix"
    checkout main
    merge hotfix/1.0.1 id: "v1.0.1" tag: "v1.0.1"
    checkout develop
    merge hotfix/1.0.1 id: "sync-hotfix"

Cấu trúc nhánh trong Git Flow

Ưu điểm của Git Flow

• Cấu trúc rõ ràng: Mỗi nhánh có mục đích cụ thể, dễ hiểu cho team mới.
• Parallel development: Nhiều feature phát triển đồng thời không ảnh hưởng nhau.
• Release kiểm soát: Quy trình release có bước chuẩn bị riêng, phù hợp với scheduled releases (mobile app, enterprise software).
• Hotfix tách biệt: Fix production không cần chờ feature đang phát triển dở.

Nhược điểm của Git Flow

• Merge hell: Feature branch sống lâu (tuần → tháng) tích lũy divergence lớn, merge về develop trở thành ác mộng.
• Feedback loop chậm: Code review xảy ra khi feature "xong hết" → PR khổng lồ, reviewer overwhelmed.
• Release bottleneck: Release branch tạo thêm ceremony — version bump, cherry-pick fix, merge ngược về develop — dễ bỏ sót.
• Không phù hợp CI/CD: Triết lý "deploy bất cứ lúc nào" mâu thuẫn với quy trình release branch kéo dài.

Trunk-Based Development là gì?

Trunk-Based Development (TBD) là mô hình trong đó tất cả developer commit trực tiếp vào một nhánh chính (trunk/main), hoặc sử dụng short-lived feature branches (tồn tại tối đa 1–2 ngày) rồi merge ngay. Không có nhánh develop, không có release branch kéo dài.

gitGraph
    commit id: "feature-a"
    branch feat/search
    checkout feat/search
    commit id: "search-v1"
    checkout main
    merge feat/search id: "merge-search"
    commit id: "feature-b"
    commit id: "feature-c"
    branch feat/filter
    checkout feat/filter
    commit id: "filter-ui"
    checkout main
    merge feat/filter id: "merge-filter" tag: "auto-deploy"
    commit id: "feature-d"
    commit id: "feature-e" tag: "auto-deploy"

Hai biến thể TBD

flowchart LR
    subgraph A["Commit trực tiếp vào Trunk"]
        A1["Developer A commit"] --> T1["main"]
        A2["Developer B commit"] --> T1
        A3["Developer C commit"] --> T1
    end
    subgraph B["Short-lived Feature Branches"]
        B1["Developer A"] --> FB1["feat/x
(sống < 2 ngày)"]
        FB1 --> T2["main"]
        B2["Developer B"] --> FB2["feat/y
(sống < 1 ngày)"]
        FB2 --> T2
    end
    style T1 fill:#e94560,stroke:#fff,color:#fff
    style T2 fill:#e94560,stroke:#fff,color:#fff
    style FB1 fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style FB2 fill:#f8f9fa,stroke:#e94560,color:#2c3e50

Ưu điểm của TBD

• Merge conflict tối thiểu: Branch sống ngắn = ít divergence = ít xung đột.
• CI/CD tự nhiên: Main luôn ở trạng thái deployable, pipeline chạy liên tục trên mỗi commit.
• Code review nhanh: PR nhỏ (vài chục → vài trăm dòng) review trong 15–30 phút thay vì hàng giờ.
• Feedback loop nhanh: Developer biết code có lỗi trong vài phút thay vì cuối sprint.
• DORA-proven: Nghiên cứu DORA chỉ ra TBD là đặc điểm chung của Elite performing teams.

Nhược điểm của TBD

• Yêu cầu automated testing mạnh: Không có test tốt, code lỗi sẽ ảnh hưởng toàn team ngay lập tức.
• Feature flags cần thiết: Feature chưa hoàn thành phải ẩn sau flag, tăng complexity quản lý.
• Đòi hỏi discipline: Developer phải commit thường xuyên, chia nhỏ task, không "ôm code" nhiều ngày.
• Khó áp dụng cho team junior nhiều: Cần hiểu biết về CI/CD, testing, và feature flag.

GitHub Flow và GitLab Flow

Ngoài Git Flow và TBD, có hai mô hình trung gian phổ biến:

flowchart TB
    subgraph GHF["GitHub Flow"]
        direction LR
        M1["main
(luôn deployable)"]
        F1["feature branch"] -->|PR + Review| M1
        M1 -->|Deploy ngay| P1["Production"]
    end
    subgraph GLF["GitLab Flow"]
        direction LR
        M2["main"]
        F2["feature branch"] -->|MR + Review| M2
        M2 --> E1["pre-production"]
        E1 --> E2["production"]
    end
    style M1 fill:#e94560,stroke:#fff,color:#fff
    style M2 fill:#e94560,stroke:#fff,color:#fff
    style P1 fill:#4CAF50,stroke:#fff,color:#fff
    style E2 fill:#4CAF50,stroke:#fff,color:#fff
    style E1 fill:#ff9800,stroke:#fff,color:#fff

So sánh chi tiết: Git Flow vs Trunk-Based Development

Feature Flags — Chìa khóa cho Trunk-Based Development

Feature flags (hay feature toggles) là kỹ thuật cho phép bật/tắt tính năng mà không cần deploy lại. Đây là thành phần thiết yếu giúp TBD hoạt động an toàn — developer có thể merge code chưa hoàn thành vào main mà không ảnh hưởng user.

flowchart LR
    DEV["Developer merge
feature chưa xong"] --> MAIN["main branch"]
    MAIN --> DEPLOY["Deploy to Production"]
    DEPLOY --> FF{"Feature Flag
ON / OFF?"}
    FF -->|ON cho internal| BETA["Beta Users
thấy feature mới"]
    FF -->|OFF cho public| PROD["Public Users
không thấy gì"]
    FF -->|Gradual rollout| CANARY["5% → 25% → 100%"]

    style MAIN fill:#e94560,stroke:#fff,color:#fff
    style FF fill:#ff9800,stroke:#fff,color:#fff
    style BETA fill:#4CAF50,stroke:#fff,color:#fff
    style PROD fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style CANARY fill:#2196F3,stroke:#fff,color:#fff

Các loại Feature Flag

DORA Metrics và Branching Strategy

Nghiên cứu DORA (DevOps Research and Assessment) từ Google cung cấp dữ liệu thực tế về mối quan hệ giữa branching strategy và delivery performance. Từ năm 2025, DORA framework mở rộng thêm metric thứ 5 — Rework Rate — và chuyển từ 4 tầng (Elite/High/Medium/Low) sang 7 team archetypes dựa trên cả delivery performance lẫn human factors.

flowchart TB
    subgraph DORA["5 DORA Metrics (2025+)"]
        DF["Deployment
Frequency"]
        LT["Lead Time
for Changes"]
        CFR["Change Failure
Rate"]
        MTTR["Mean Time
to Recovery"]
        RR["Rework Rate
(mới 2025)"]
    end

    subgraph ELITE["Elite Performers"]
        E1["Deploy: nhiều lần/ngày"]
        E2["Lead time: < 1 giờ"]
        E3["Failure rate: 0-5%"]
        E4["Recovery: < 1 giờ"]
        E5["Rework: < 10%"]
    end

    TBD["Trunk-Based
Development"] -->|"enables"| ELITE

    style TBD fill:#e94560,stroke:#fff,color:#fff
    style DF fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style LT fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style CFR fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style MTTR fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style RR fill:#f8f9fa,stroke:#e94560,color:#2c3e50

Khi nào chọn Git Flow, khi nào chọn TBD?

flowchart TD
    START["Team của bạn"] --> Q1{"Deploy frequency?"}
    Q1 -->|"Hàng ngày /
nhiều lần/ngày"| TBD_REC["→ Trunk-Based Development"]
    Q1 -->|"Hàng tuần /
hàng tháng"| Q2{"Cần maintain
nhiều version?"}
    Q2 -->|Có| GF_REC["→ Git Flow"]
    Q2 -->|Không| Q3{"Team size?"}
    Q3 -->|"≤ 5 người"| GHF_REC["→ GitHub Flow"]
    Q3 -->|"> 5 người"| Q4{"Có staging
environment?"}
    Q4 -->|Có| GLF_REC["→ GitLab Flow"]
    Q4 -->|Không| TBD_REC2["→ Trunk-Based
+ Feature Flags"]

    style TBD_REC fill:#4CAF50,stroke:#fff,color:#fff
    style TBD_REC2 fill:#4CAF50,stroke:#fff,color:#fff
    style GF_REC fill:#2196F3,stroke:#fff,color:#fff
    style GHF_REC fill:#ff9800,stroke:#fff,color:#fff
    style GLF_REC fill:#9C27B0,stroke:#fff,color:#fff
    style START fill:#e94560,stroke:#fff,color:#fff

Chuyển đổi từ Git Flow sang Trunk-Based Development

Nếu team đang dùng Git Flow và muốn chuyển sang TBD, đây là lộ trình từng bước thay vì "big bang":

Best Practices cho Trunk-Based Development

1. Small Batch Size

Mỗi PR nên thay đổi dưới 400 dòng code. Nghiên cứu từ Google cho thấy PR trên 400 dòng có review quality giảm đáng kể — reviewer bắt đầu skim thay vì đọc kỹ. Chia feature lớn thành nhiều PR liên tiếp, mỗi PR tự chứa và deployable.

2. Pre-commit Checks

# .husky/pre-commit hoặc CI pipeline
npm run lint
npm run type-check
npm run test:unit -- --changed

Chạy lint, type-check, và unit test trên code thay đổi trước khi push. Giảm thời gian CI feedback từ phút xuống giây.

3. Branch Protection Rules

# GitHub branch protection cho main
- Require pull request reviews (≥ 1 approval)
- Require status checks to pass (CI pipeline)
- Require branches to be up to date
- Do NOT require linear history (cho phép merge commits)

4. Commit Message Convention

# Conventional Commits
feat(auth): add OAuth2 login flow
fix(cart): resolve race condition in quantity update
refactor(api): extract validation middleware
chore(deps): bump express to 4.21.0

Conventional Commits giúp auto-generate changelog, semantic versioning, và dễ đọc git log.

5. Ship/Show/Ask Framework

Thực tế tại các công ty lớn

Tổng kết

Không có branching strategy nào là "đúng" cho mọi team. Git Flow vẫn hợp lý cho software cần versioning rõ ràng và scheduled releases (mobile app, SDK, enterprise). Nhưng cho web application, SaaS, và bất kỳ team nào muốn deploy thường xuyên, Trunk-Based Development kết hợp feature flags là lựa chọn được DORA research chứng minh hiệu quả.

Điều quan trọng nhất không phải chọn mô hình nào, mà là team có automated testing đủ mạnh để tự tin merge code thường xuyên, và culture tin tưởng để mọi người commit nhỏ, review nhanh, và ship liên tục.

Nguồn tham khảo:

• Atlassian — Trunk-Based Development
• Toptal — Trunk-based Development vs. Git Flow
• DORA Metrics Benchmarks 2026
• Mergify — Trunk-Based Development vs Gitflow
• PostHog — How we do trunk-based development
• DORA Metrics Are Not Enough in 2026