Login

Git Flow hay trunk-based: chọn chiến lược nhánh cho nhóm của bạn

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Nhóm bốn người, mỗi người một nhánh, cuối tuần gộp lại và nổ ra mười lăm xung đột. Nghe quen không? Cách tổ chức nhánh Git ảnh hưởng trực tiếp đến tốc độ phát hành và mức độ đau đầu của cả đội. Dưới đây là hai trường phái phổ biến và cách chọn.

Git Flow: nhiều nhánh có vai trò rõ ràng

Git Flow dùng một bộ nhánh cố định:

  • main: mã đang chạy production, mỗi lần phát hành được gắn tag.
  • develop: nhánh tích hợp cho bản phát hành kế tiếp.
  • feature/*: mỗi tính năng một nhánh, tách từ develop và gộp lại vào develop.
  • release/*: chuẩn bị phát hành, chỉ sửa lỗi nhỏ và cập nhật phiên bản.
  • hotfix/*: sửa khẩn cấp từ main.

Hợp khi sản phẩm có nhiều phiên bản cần hỗ trợ song song, chu kỳ phát hành theo lịch cố định, hoặc phần mềm cài đặt và ứng dụng di động cần qua duyệt cửa hàng. Nhược điểm: nhiều nhánh sống lâu dễ sinh xung đột lớn, quy trình nặng nề hơn so với nhu cầu của đội web nhỏ.

Trunk-based development: một nhánh chính, thay đổi nhỏ và thường xuyên

Mọi người làm việc trên một nhánh chính (trunk, thường là main). Nhánh phụ nếu có thì rất ngắn, sống vài giờ đến một hai ngày rồi gộp lại. Thay đổi nhỏ, gộp liên tục.

Để làm được, bạn cần:

  1. CI mạnh: mọi thay đổi gộp vào main đều qua kiểm tra tự động.
  2. Feature flag: tính năng chưa xong vẫn đưa lên main nhưng tắt đi.
  3. Review nhanh: pull request nhỏ, được xem trong thời gian ngắn.
  4. Văn hóa sửa ngay: main hỏng thì ưu tiên sửa trước mọi việc khác.

Hợp khi làm dịch vụ web triển khai liên tục, nhóm có kỷ luật kiểm thử. Nhược điểm: đòi hỏi trình độ tự động hóa và kỷ luật cao hơn, ban đầu có thể thấy áp lực.

GitHub Flow: bản đơn giản ở giữa

Một biến thể nhẹ nhàng thường dùng: main luôn có thể triển khai; mỗi việc tạo nhánh từ main, mở pull request, review, kiểm tra tự động qua rồi gộp vào main và triển khai. Không có develop, không có release. Đây là điểm khởi đầu rất tốt cho đa số nhóm nhỏ.

So sánh nhanh

Tiêu chíGit FlowGitHub FlowTrunk-based
Số nhánh dài hạn2 (main, develop)11
Tần suất phát hànhTheo đợtLiên tụcRất thường xuyên
Độ phức tạpCaoThấpThấp nhưng cần kỷ luật
Phụ thuộc CI/CDVừaCaoRất cao

Quy ước đặt tên và commit giúp ích cho mọi chiến lược

  • Tên nhánh: feature/dang-nhap, fix/loi-thanh-toan.
  • Commit nhỏ, thông điệp nói rõ lý do thay đổi.
  • Bảo vệ nhánh chính: bắt buộc pull request và kiểm tra tự động qua mới được gộp.
  • Xóa nhánh sau khi gộp để kho gọn gàng.
  • Cập nhật nhánh làm việc từ main thường xuyên để tránh xung đột dồn lại.

Cách chọn

  1. Nhóm nhỏ, web, có CI: bắt đầu với GitHub Flow.
  2. Đã có thói quen kiểm thử tự động tốt và muốn phát hành nhiều lần mỗi ngày: hướng tới trunk-based cùng feature flag.
  3. Có nhiều phiên bản phát hành song song hoặc kiểm duyệt dài: Git Flow hoặc biến thể của nó.

Đừng chọn theo mốt. Hãy xem nỗi đau lớn nhất của nhóm là gì (xung đột, phát hành chậm, lỗi lọt qua) rồi chọn cách giải quyết nó.

Kết luận

Không có chiến lược nhánh nào đúng tuyệt đối, chỉ có cái hợp với đội bạn ở thời điểm hiện tại. Quan trọng là cả nhóm thống nhất, ghi lại quy tắc và điều chỉnh khi thấy không còn hiệu quả.

Nếu bạn muốn nắm vững Git và quy trình làm việc nhóm, hãy tham khảo các bài học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment