Git Flow: nó là gì, mô hình rẽ nhánh và sử dụng trong các dự án

Git Flow là gì?

Git Flow là mô hình rẽ nhánh Git xác định cấu trúc nghiêm ngặt của các nhánh và quy tắc hợp nhất để quản lý phát triển, phát hành và sửa lỗi. Vincent Driessen đã đăng bài viết “A successful Git branching model” vào tháng 1 năm 2010, và kể từ đó Git Flow đã trở thành tiêu chuẩn thực tế trong phát triển doanh nghiệp Java và .NET. Ý tưởng chính là chia mã thành năm loại nhánh với các mức độ ổn định khác nhau.

Theo Atlassian Git Tutorials, 2024, Git Flow dựa trên hai nhánh vĩnh viễn: main (trước đây là master) và develop. Tất cả các nhánh khác đều tạm thời: feature, release, hotfix. Mỗi loại nhánh có vòng đời và quy tắc hợp nhất được xác định rõ ràng. Trong phát triển di động, Git Flow được sử dụng trong các dự án có chu kỳ phát hành định kỳ (2–4 tuần) và hỗ trợ nhiều phiên bản.

Git Flow khác với các mô hình đơn giản (GitHub Flow) ở chỗ yêu cầu một nhánh develop riêng biệt cho tích hợp. Điều này thêm một bước vào quy trình hợp nhất, nhưng cung cấp khả năng cách ly bổ sung các tính năng chưa hoàn thành khỏi mã sẵn sàng phát hành.

Vincent Driessen và lịch sử của Git Flow

Vào năm 2010, Vincent Driessen đã đăng bài viết “A successful Git branching model”, trở thành một trong những bài được trích dẫn nhiều nhất trong lịch sử Git. Mô hình được tạo ra cho một dự án có các bản phát hành cố định và hỗ trợ phiên bản song song. Vào năm 2020, Driessen thừa nhận rằng Git Flow đã lỗi thời cho các thực hành CI/CD hiện đại, nhưng mô hình vẫn phù hợp với các dự án có chu kỳ phát hành dài và cần hỗ trợ các phiên bản cũ.

# Khởi tạo Git Flow
git flow init

# Tạo nhánh feature
git flow feature start "add-auth"

# Kết thúc nhánh feature (hợp nhất vào develop)
git flow feature finish "add-auth"

# Tạo release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Nhánh Main: mã phát hành và gắn thẻ

Main (trước đây là master) là nhánh chính chỉ chứa mã phát hành sẵn sàng để triển khai. Mỗi commit trong main phải tương ứng với một phiên bản sản phẩm cụ thể, được gắn thẻ theo định dạng phiên bản ngữ nghĩa, ví dụ v1.0.0, v1.1.0. Không có phát triển trực tiếp nào trong main — các thay đổi chỉ đến đây thông qua các nhánh release hoặc hotfix.

Theo semver.org, 2024, các thẻ trong main sử dụng định dạng MAJOR.MINOR.PATCH. MAJOR được tăng cho các thay đổi API không tương thích, MINOR cho việc thêm chức năng tương thích ngược, PATCH cho sửa lỗi. Trong Git Flow, mỗi lần kết thúc release sẽ tự động tạo một commit trong main với thẻ phiên bản.

Nhánh Main là nhánh duy nhất được triển khai lên sản xuất. Đối với các dự án di động, điều này có nghĩa là push lên main sẽ kích hoạt đường ống xây dựng App Bundle hoặc IPA và xuất bản lên Google Play / App Store. Trong cài đặt CI/CD của GitLab, main được bảo vệ khỏi force-push và xóa.

Phiên bản ngữ nghĩa và thẻ

Mỗi commit trong main đi kèm với một thẻ ở định dạng SemVer: vMAJOR.MINOR.PATCH. MAJOR — cho các thay đổi API không tương thích, MINOR — cho chức năng mới tương thích ngược, PATCH — cho sửa lỗi. Ví dụ: v2.1.0 có nghĩa là bản phát hành chính thứ hai với các tính năng mới và không có sửa lỗi. Trong Git Flow, các thẻ được tạo tự động khi kết thúc release hoặc hotfix thông qua lệnh git flow release finish.

Nhánh Develop: đường tích hợp phát triển

Develop là nhánh vĩnh viễn thứ hai trong Git Flow, được thiết kế để tích hợp tất cả các tính năng đã hoàn thành. Các nhà phát triển hợp nhất các nhánh feature vào develop sau khi vượt qua đánh giá mã và kiểm tra CI/CD. Develop chứa phiên bản ổn định mới nhất của mã, bao gồm tất cả các tính năng đã triển khai của sprint hiện tại.

Theo DataSift Git Flow Guide, 2024, develop có thể tạm thời không ổn định do các tích hợp đang diễn ra. Để ngăn ngừa sự cố, các nhóm thực hành Tích hợp Liên tục (CI): mỗi tính năng phải vượt qua một bộ kiểm thử đầy đủ trước khi hợp nhất vào develop. Nếu CI thất bại, nhà phát triển sửa mã trước lần hợp nhất tiếp theo. Develop luôn gắn với phiên bản hiện tại của main: ngay sau khi phát hành, develop được đồng bộ với main thông qua hợp nhất.

Nhánh Feature: phát triển chức năng mới

Các nhánh Feature là các nhánh tạm thời để phát triển các tính năng riêng lẻ, sửa lỗi hoặc thử nghiệm. Mỗi nhánh feature được tạo từ develop và được hợp nhất trở lại develop sau khi hoàn thành. Tên nhánh feature thường chứa số nhiệm vụ hoặc mô tả ngắn gọn: feature/APP-123-add-oauth, feature/redesign-profile. Trong Git Flow, các nhánh feature có thể tồn tại vô thời hạn.

Theo Pro Git Book, 2024, các nhánh feature là môi trường phát triển cô lập: các thay đổi trong một nhánh không ảnh hưởng đến các nhánh khác cho đến khi hợp nhất. Trong các dự án di động, các nhánh feature được đồng bộ với develop thông qua rebase hoặc merge để tránh xung đột lớn khi kết thúc. Nên rebase nhánh feature lên develop trước khi tạo MR.

# Tạo nhánh feature thủ công (không có git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Tạo MR trong GitLab qua CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Nhánh Release: chuẩn bị phát hành

Các nhánh Release là các nhánh tạm thời được tạo từ develop để chuẩn bị phát hành. Khi develop chứa đủ các tính năng cho một phiên bản mới, nhóm sẽ tạo nhánh release/X.Y.Z (ví dụ: release/2.1.0). Trong nhánh này chỉ thực hiện các thay đổi cuối cùng: tăng phiên bản, cập nhật bản địa hóa, kiểm thử cuối cùng, sửa lỗi nghiêm trọng.

Theo Atlassian Git Tutorials, 2024, nhánh release giải quyết một vấn đề chính: cách ly các thay đổi cuối cùng khỏi phát triển song song. Trong khi bản phát hành đang được chuẩn bị, các tính năng mới cho bản phát hành tiếp theo tiếp tục được hợp nhất vào develop. Sau khi hoàn thành, nhánh release được hợp nhất vào main (có thẻ) và vào develop (để đồng bộ việc tăng phiên bản).

Nhánh Hotfix: sửa lỗi khẩn cấp trong sản xuất

Các nhánh Hotfix là các nhánh tạm thời để sửa các lỗi nghiêm trọng khẩn cấp trong sản xuất. Loại nhánh duy nhất trong Git Flow được tạo từ main thay vì develop. Định dạng tên: hotfix/X.Y.Z+1 (ví dụ: hotfix/2.1.1). Sau khi hoàn thành, nhánh hotfix được hợp nhất đồng thời vào main (như một bản phát hành vá) và vào develop (để sửa lỗi không bị mất trong các bản phát hành tương lai).

Theo DataSift Git Flow Guide, 2024, các nhánh hotfix nên ngắn nhất có thể — chỉ sửa lỗi và kiểm thử. Hotfix không được bao gồm các tính năng mới hoặc tái cấu trúc. Trong phát triển di động, hotfix được sử dụng để sửa các sự cố nghiêm trọng (tỷ lệ crash > 0.1%), lỗ hổng bảo mật hoặc lỗi chặn trong App Store.

Ưu và nhược điểm của Git Flow cho phát triển di động

Git Flow cung cấp một cấu trúc rõ ràng đặc biệt hữu ích cho các nhóm lớn và các dự án có bản phát hành định kỳ. Ưu điểm: cách ly các tính năng chưa hoàn thành trong các nhánh feature, khả năng chuẩn bị phát hành mà không chặn phát triển, hỗ trợ nhiều phiên bản thông qua hotfix. Nhược điểm: phức tạp đối với người mới, cần rebase thường xuyên các nhánh feature, xung đột với các nhánh tồn tại lâu.

Theo Martin Fowler, 2024, nhược điểm chính của Git Flow là các nhánh feature tồn tại lâu. Nếu một tính năng được phát triển trong 2+ tuần mà không đồng bộ với develop, xung đột hợp nhất sẽ trở nên đáng kể. Đối với các dự án di động, nên đồng bộ nhánh feature hàng ngày thông qua rebase lên develop.

Git Flow không được khuyến nghị cho các dự án có Triển khai Liên tục (mỗi commit trong main → sản xuất). Đối với các dự án đó, GitHub Flow hoặc Trunk-Based Development cung cấp một mô hình đơn giản hơn và nhanh hơn. Nhưng đối với các dự án có chu kỳ phát hành và hỗ trợ các phiên bản cũ, Git Flow vẫn là lựa chọn tối ưu.

Khi nào Git Flow gây hại cho nhóm

Git Flow trở thành vấn đề trong ba trường hợp: nhóm ít hơn 5 người (phức tạp không cần thiết), Triển khai Liên tục (chậm trễ giao hàng), thiếu kỷ luật rebase (các nhánh feature tồn tại lâu tạo ra xung đột hợp nhất). Nếu một nhóm dành hơn 20% thời gian cho việc hợp nhất nhánh và giải quyết xung đột — Git Flow không phù hợp với nhóm đó, ngay cả khi nhóm lớn.

Các lựa chọn thay thế Git Flow: GitHub Flow và Trunk-Based Development

Các lựa chọn thay thế Git Flow cung cấp một quy trình đơn giản hơn cho các nhóm thực hành CI/CD. GitHub Flow chỉ sử dụng một nhánh vĩnh viễn (main) và các nhánh feature. Mỗi tính năng được tạo từ main, sau khi review và CI được hợp nhất trở lại main và triển khai ngay lập tức. GitHub Flow đơn giản hơn nhưng không hỗ trợ cách ly các tính năng chưa hoàn thành hoặc chuẩn bị phát hành song song.

Theo GitHub Docs, 2024, Trunk-Based Development (TBD) tiến xa hơn: tất cả các nhà phát triển làm việc trong một nhánh duy nhất (trunk), sử dụng các nhánh feature ngắn hạn 1–2 ngày. Feature toggles kiểm soát khả năng hiển thị của mã chưa hoàn thành. TBD đòi hỏi kỷ luật CI/CD cao và tự động hóa kiểm thử.

• GitHub Flow — một main + các nhánh feature, lý tưởng cho CI/CD và nhóm nhỏ
• GitLab Flow — mở rộng Git Flow với các nhánh môi trường (staging, production)
• Trunk-Based Development — một nhánh + feature toggles, CI/CD tối đa, hợp nhất tối thiểu
• One Flow — Git Flow đơn giản hóa không có nhánh develop, chỉ main + feature + release