So sánh Git Workflows: Gitflow vs GitHub Flow vs Trunk-Based Development – Dự án nào nên dùng?
Phân tích Gitflow vs GitHub Flow vs Trunk-Based Development: cấu trúc branch, ưu nhược điểm, điều kiện áp dụng, ma trận quyết định và lộ trình chuyển đổi cho từng loại dự án.
ShanverseCập nhật 12 phút đọc— lượt xemĐang tải lượt xem
Git
Developer Tools
Ba mô hình thường được so sánh:
Gitflow: nhiều branch dài hạn và branch theo giai đoạn release.
GitHub Flow: một branch chính, feature branch ngắn, Pull Request và deploy liên tục.
Trunk-Based Development (TBD): mọi người tích hợp vào trunk rất thường xuyên, branch cực ngắn và dùng feature flags để tách deploy khỏi release.
Bài viết này không chỉ hỏi “mô hình nào đơn giản hơn”, mà sẽ phân tích dự án nào thực sự phù hợp với từng workflow.
Trước khi chọn workflow: hỏi 7 câu
Production được deploy mỗi ngày, mỗi tuần hay vài tháng một lần?
Team có CI nhanh và đáng tin cậy không?
Có thể ẩn code chưa hoàn tất bằng feature flag không?
Bình luận
Có phải duy trì nhiều phiên bản production song song không?
Release có giai đoạn freeze, QA hoặc phê duyệt bắt buộc không?
Pull Request thường sống bao lâu?
Khi lỗi xảy ra, team rollback/hotfix trong bao lâu?
Nếu chưa trả lời được, việc chọn workflow theo trend dễ tạo quy trình không phù hợp.
Bảng so sánh nhanh
1. Gitflow là gì?
Gitflow thường có hai branch dài hạn:
main: lịch sử production/release.
develop: nơi tích hợp cho release kế tiếp.
Các branch hỗ trợ:
feature/*: phát triển tính năng từ develop.
release/*: ổn định release trước khi lên main.
hotfix/*: sửa production gấp từ main.
Mermaid
Loading diagram…
Quy trình điển hình
Hotfix:
Điểm mạnh của Gitflow
Tách rõ code production và code chuẩn bị release.
Có nơi dành riêng cho release stabilization/QA.
Hỗ trợ release theo phiên bản và lịch cố định.
Dễ hình dung hotfix production tách khỏi feature mới.
Phù hợp khi cần duy trì release branch trong một giai đoạn.
Điểm yếu của Gitflow
Nhiều branch và nhiều hướng merge.
Code sống xa production lâu hơn.
Conflict xuất hiện muộn khi feature/release branch tồn tại dài.
Dễ bỏ sót merge ngược hotfix vào develop.
Khó đạt continuous deployment thực sự.
Chi phí quản trị tăng theo số branch và phiên bản.
Dự án phù hợp với Gitflow
Phần mềm đóng gói phát hành theo version.
Mobile/desktop app có chu kỳ store review.
Sản phẩm on-premise cần hỗ trợ nhiều phiên bản.
Dự án có giai đoạn release freeze và QA độc lập.
Môi trường regulated cần cổng phê duyệt rõ ràng.
Team chưa thể deploy từng thay đổi nhỏ nhưng vẫn cần cấu trúc release.
Dự án không nên mặc định dùng Gitflow
SaaS deploy nhiều lần mỗi ngày.
Team nhỏ chỉ có một production version.
CI/CD tốt và feature flag trưởng thành.
Repository có hàng trăm contributor cần tích hợp nhanh.
2. GitHub Flow là gì?
GitHub Flow xoay quanh một branch chính luôn có thể deploy:
Tạo branch từ main.
Commit và push.
Mở Pull Request.
Review + CI.
Merge vào main.
Deploy từ main.
Mermaid
Loading diagram…
Quy trình điển hình
Sau khi checks pass và review hoàn tất, merge PR. Branch bị xóa.
Điểm mạnh của GitHub Flow
Dễ hiểu, ít branch dài hạn.
Pull Request là điểm review và audit rõ ràng.
Feedback nhanh hơn Gitflow.
Phù hợp CI/CD và deploy từ main.
Onboarding đơn giản cho team nhỏ–vừa.
Hotfix dùng cùng một quy trình, không cần loại branch đặc biệt.
Điểm yếu của GitHub Flow
main phải thực sự luôn deployable.
Feature lớn dễ biến thành PR sống lâu.
Code chưa hoàn tất cần feature flag hoặc chia nhỏ.
Không cung cấp sẵn mô hình quản lý nhiều version.
Nếu review/CI chậm, branch vẫn bị kéo dài và conflict tăng.
Dự án phù hợp với GitHub Flow
SaaS, web app và API có một production line chính.
Team deploy hàng ngày hoặc hàng tuần.
Mọi thay đổi đi qua Pull Request và automated checks.
Team nhỏ–vừa cần quy trình rõ, không quá phức tạp.
Có thể rollback nhanh hoặc dùng feature flag cho thay đổi lớn.
Khi GitHub Flow cần bổ sung release branch
Một số sản phẩm deploy liên tục nhưng vẫn hỗ trợ release cũ. Có thể dùng main theo GitHub Flow và tạo branch bảo trì khi cần:
Đây là biến thể thực dụng, không nhất thiết phải áp dụng toàn bộ Gitflow.
3. Trunk-Based Development là gì?
TBD yêu cầu mọi developer tích hợp vào một trunk chung ít nhất mỗi ngày, thường nhiều lần mỗi ngày.
Hai dạng phổ biến:
Team nhỏ commit trực tiếp vào trunk với CI và pair review.
Team lớn dùng branch/PR cực ngắn, thường không quá một–hai ngày.
Mermaid
Loading diagram…
Điểm cốt lõi không phải “không bao giờ tạo branch”, mà là không để branch tách khỏi trunk đủ lâu để trở thành dòng phát triển riêng.
Các kỹ thuật nền tảng
Feature flags.
Branch by abstraction.
Small batch/vertical slice.
CI nhanh và ổn định.
Automated tests mạnh.
Observability và rollback nhanh.
Backward-compatible database migration.
Điểm mạnh của TBD
Conflict nhỏ và được xử lý sớm.
Feedback từ tích hợp rất nhanh.
Giảm inventory code chưa tích hợp.
Hỗ trợ continuous integration đúng nghĩa.
Dễ đạt deployment frequency cao.
Mọi người làm việc gần trạng thái production.
Điểm yếu và điều kiện khó
Đòi hỏi test automation và CI trưởng thành.
Feature flag cần lifecycle, owner và cleanup.
Thay đổi database/API phải tương thích ngược.
Code review phải nhanh, phạm vi PR rất nhỏ.
Kỷ luật chia nhỏ công việc cao.
Trunk hỏng có thể chặn cả team nếu thiếu bảo vệ.
Dự án phù hợp với TBD
SaaS/cloud product deploy liên tục.
Platform/backend có pipeline tự động mạnh.
Monorepo lớn cần giảm branch divergence.
Team có khả năng chia feature thành increment nhỏ.
Có feature flag, canary, progressive delivery và rollback.
CI đủ nhanh để feedback trong vài phút.
Dự án chưa nên vội dùng TBD
Test chủ yếu thủ công.
Build/CI mất hàng giờ và thường flaky.
Release yêu cầu tích hợp hàng loạt thay đổi không thể ẩn.
Kiến trúc không hỗ trợ migration tương thích.
Team chưa có khả năng monitor/rollback nhanh.
GitHub Flow và TBD khác nhau ở đâu?
Hai mô hình có vẻ giống nhau vì đều ưu tiên main và branch ngắn.
Một team dùng GitHub Flow với PR merge trong vài giờ, feature flags và CI nhanh có thể đang vận hành rất gần TBD.
Ma trận chọn workflow theo dự án
Không chọn chỉ theo quy mô team
Team 100 người vẫn có thể dùng TBD nếu CI và ownership tốt. Team 5 người vẫn có thể cần release branch nếu phải duy trì nhiều phiên bản khách hàng.
Các yếu tố quan trọng hơn:
Lead time mong muốn.
Số production versions.
Automation maturity.
Cost of failure.
Khả năng rollback.
Compliance/review policy.
Kiến trúc ứng dụng.
Ví dụ 1: SaaS deploy nhiều lần mỗi ngày
Đề xuất: TBD hoặc GitHub Flow rất ngắn.
Quy tắc:
Feature mới:
Release do flag:
Deploy và release là hai sự kiện khác nhau.
Ví dụ 2: Mobile app release mỗi tháng
Đề xuất: GitHub Flow + release branch hoặc Gitflow nhẹ.
Tránh giữ develop nếu nó không mang lại giá trị rõ ràng. Chỉ thêm branch dài hạn khi có nhu cầu release thực tế.
Ví dụ 3: Sản phẩm on-premise hỗ trợ 3 phiên bản
Đề xuất: Gitflow hoặc maintenance branch rõ ràng.
Hotfix có thể được cherry-pick có kiểm soát sang các version phù hợp. Cần test matrix và release automation cho từng branch.
Ví dụ 4: Monorepo hàng trăm developer
Đề xuất: TBD ở quy mô lớn.
Yêu cầu:
Trunk protection.
CI phân tán và selective testing.
CODEOWNERS/review tự động.
Feature flags.
Build reproducible.
Merge queue.
Monitoring và automatic rollback.
Branch dài trong monorepo làm cross-team dependency và conflict tăng rất nhanh.
Quy tắc branch nên viết thành policy
Ví dụ GitHub Flow:
Ví dụ TBD:
Ví dụ Gitflow:
Các anti-pattern phổ biến
“Gitflow” với feature branch kéo dài nhiều tháng
Đây là delayed integration. Hãy chia nhỏ feature, merge sớm và dùng flag.
GitHub Flow nhưng main không deploy được
Nếu main thường xuyên đỏ hoặc cần sửa thủ công trước deploy, pipeline chưa đáp ứng giả định cốt lõi.
TBD nhưng PR sống một tuần
Đó không còn là trunk-based theo nghĩa tích hợp liên tục. Đặt giới hạn batch và SLA review.
Feature flag không bao giờ xóa
Flag trở thành nợ kỹ thuật và nhân đôi số trạng thái cần test. Mỗi flag cần owner, ngày hết hạn và cleanup task.
Release branch nhận feature mới không kiểm soát
Release branch nên ổn định. Việc tiếp tục thêm feature làm freeze mất ý nghĩa.
Copy workflow của công ty lớn
Công ty lớn có tooling, merge queue và test infrastructure khác. Chọn nguyên tắc phù hợp với năng lực hiện tại.
Chỉ số cho biết workflow đang có vấn đề
Theo dõi:
Tuổi trung bình của branch/PR.
Thời gian từ first commit đến production.
Tỷ lệ conflict/rebase.
CI duration và flaky rate.
Deployment frequency.
Change failure rate.
Mean time to restore.
Số hotfix bị quên đồng bộ sang branch khác.
Dấu hiệu cảnh báo:
PR thường trên một tuần.
Release merge conflict kéo dài nhiều ngày.
develop và main khác nhau không rõ lý do.
Team ngại merge vì CI không đáng tin.
Feature flag tồn tại vô thời hạn.
Lộ trình chuyển đổi workflow
Gitflow → GitHub Flow
Xác định có thực sự cần develop không.
Làm main luôn build/test được.
Rút ngắn feature branches.
Deploy từ main vào staging trước.
Chỉ giữ release branches cho version cần bảo trì.
Tự động hóa rollback và hotfix.
GitHub Flow → TBD
Giảm PR xuống dưới một ngày.
Nâng tốc độ và độ tin cậy CI.
Áp dụng feature flags.
Chia feature theo vertical slices.
Thiết kế migration tương thích ngược.
Thêm merge queue/progressive delivery.
TBD → workflow có release branch
TBD không cấm release branch. Với sản phẩm versioned, trunk vẫn là nơi tích hợp chính; branch release chỉ dùng stabilization/maintenance và không trở thành dòng feature thứ hai.
Cách chọn trong 30 giây
Mermaid
Loading diagram…
Checklist trước khi chốt workflow
Đã xác định nhịp release thực tế.
Biết số phiên bản cần bảo trì song song.
Có SLA cho CI và code review.
Đã định nghĩa main/trunk “xanh” nghĩa là gì.
Có quy trình rollback/hotfix.
Có policy branch lifetime.
Có owner và cleanup cho feature flags.
Có migration strategy tương thích ngược.
Có branch protection và required checks.
Workflow được đo bằng lead time/chất lượng, không chỉ số branch.
Team review lại workflow định kỳ.
Kết luận
Chọn Gitflow khi release theo đợt, cần stabilization rõ và duy trì nhiều phiên bản.
Chọn GitHub Flow khi muốn quy trình PR đơn giản, main deployable và release khá thường xuyên.
Chọn Trunk-Based Development khi có CI/CD trưởng thành, feature flags và khả năng tích hợp nhiều lần mỗi ngày.
Dùng hybrid có chủ đích khi cần: trunk/main cho tích hợp, release branch chỉ cho maintenance.
Mục lục(43)
Codeplain text
1main → phát triển hiện tại2release/2.4 → patch cho khách hàng còn ở 2.43release/2.3 → chỉ security fixes
Codeplain text
1main luôn xanh2PR < 1 ngày3CI < 10 phút4feature lớn nằm sau flag5progressive rollout + rollback tự động
Codeplain text
1Deploy code → bật 5% người dùng → monitor → 50% → 100%
Codeplain text
1main → phiên bản tiếp theo2release/3.8 → QA và store submission3hotfix từ release/3.8 → patch store nếu cần
Codeplain text
1main / develop → phiên bản tương lai2release/5.x → khách hàng mới3release/4.x → security + critical fixes4release/3.x → extended support
Codeplain text
1- main luôn deployable2- mọi thay đổi qua PR3- branch tối đa 3 ngày4- CI bắt buộc pass5- squash merge6- branch tự xóa sau merge
Codeplain text
1- tích hợp trunk ít nhất mỗi ngày2- PR mục tiêu < 400 dòng và < 1 ngày3- feature chưa hoàn tất phải có flag4- migration tương thích ngược5- trunk đỏ được ưu tiên số 1
Codeplain text
1- feature từ develop2- release branch chỉ nhận bugfix/release metadata3- hotfix từ production tag/main4- mọi hotfix merge/cherry-pick trở lại develop và release đang hỗ trợ5- branch owner và ngày hết hạn rõ ràng
Codebash
1# Tạo feature từ develop2gitswitchdevelop3gitpull--ff-only4gitswitch-cfeature/checkout56# Hoàn tất feature và merge về develop7# Sau đó tạo release branch8gitswitch-crelease/2.4develop910# Ổn định, sửa version, QA rồi merge vào main và develop
Codebash
1gitswitchmain2gitswitch-chotfix/payment-timeout3# sửa, test, merge về main và develop
Codebash
1gitswitchmain2gitpull--ff-only3gitswitch-cfeature/checkout-validation45# commit nhỏ, push và mở PR6gitpush-uoriginfeature/checkout-validation
Codebash
1gitswitch-cfeature/new-checkout-step2# thay đổi nhỏ, test, PR, merge trong ngày
Bài viết liên quan
Những bài viết có cùng chủ đề hoặc công nghệ bạn có thể muốn đọc tiếp.
Hướng dẫn Git Aliases và .gitconfig thực chiến: alias an toàn, log đẹp, cấu hình pull/push/rebase, includeIf cho tài khoản work/personal, bảo mật và chia sẻ dotfiles.
Hướng dẫn git worktree từ cơ bản đến thực tế: tạo nhiều working tree, làm feature và hotfix song song, review PR, quản lý list/remove/prune/lock/repair và tránh lỗi phổ biến.
