016 — Trunk-Based Development: Vì Sao Bỏ Mô Hình GitFlow Cũ?
Caption
Trunk-Based Development: Bí quyết deploy 50 lần/ngày của các tập đoàn công nghệ
Ngay cả Vincent Driessen (tác giả tạo ra GitFlow năm 2010) cũng đã bổ sung ghi chú phản tỉnh vào năm 2020: Nếu đội ngũ của bạn đang làm Continuous Delivery, GitFlow không còn phù hợp nữa — hãy chuyển sang quy trình tinh gọn hơn như Trunk-Based Development!
Mô hình GitFlow truyền thống thường giữ nhánh feature hàng tuần, dẫn đến:
❌ Code drift quá xa nhánh chính.
❌ Merge conflict khổng lồ ("Merge Hell") mỗi kỳ release.
❌ Khó kiểm thử tích hợp sớm, phát hiện bug muộn.
Trunk-Based Development giải quyết thế nào?
1. Short-lived branch: Nhánh tính năng chỉ sống vài giờ đến tối đa 1–2 ngày. Báo cáo DORA chỉ ra nhóm Elite DevOps luôn merge code vào trunk ít nhất 1 lần mỗi ngày.
2. CI tự động chạy ngay khi push: Tích hợp liên tục, tự động test và phản hồi kết quả trong vài phút.
3. Feature Flags (OpenFeature): Code tính năng dở dang vẫn được merge an toàn lên trunk nhưng ẩn sau cờ tính năng. Cho phép rollout dần (1% → 10% → 100%) và có kill-switch tắt tức thì khi có sự cố mà không cần rollback code.
💡 Mẹo CLI tìm nhánh "sống quá lâu" trong repo:
git for-each-ref --sort=committerdate --format='%(committerdate:relative) %(refname:short)' refs/remotes/origin