Gitflow Giải Thích: Branching Model Mà Dev Nào Cũng Nên Biết

Bạn vừa join team mới. Clone repo, tạo branch, push code... rồi bỗng dưng code của đồng nghiệp biến mất. Senior dev nhắn Slack: "Ê, mày vừa push thẳng lên main à?"

Nghe quen không? Đây chính là lý do các team dùng branching model — và cái nổi tiếng nhất là Gitflow.

Được tạo bởi Vincent Driessen năm 2010, Gitflow là một branching strategy có cấu trúc rõ ràng, mỗi loại công việc có "làn đường" riêng. Nó không phải model duy nhất, nhưng hiểu được nó sẽ giúp bạn làm việc nhóm tốt hơn — kể cả khi team bạn dùng model đơn giản hơn.

Bạn Sẽ Học Được Gì

✅ Gitflow là gì và tại sao nó tồn tại
✅ 5 loại branch và mục đích của từng loại
✅ Workflow từng bước cho feature, release, và hotfix
✅ Khi nào dùng Gitflow, khi nào dùng model đơn giản hơn
✅ Những lỗi hay gặp và cách tránh

Gitflow Giải Quyết Vấn Đề Gì?

Không Có Branching Model

Tưởng tượng team 5 developer, ai cũng push thẳng lên main:

# Sáng thứ Hai
git pull origin main        # 3 conflict từ thứ Sáu
git push origin main        # CI pipeline tèo
# Ai đó deploy code lỗi lên production 💥

Chuyện gì xảy ra:

• Không phân biệt được code "đang làm" và code "sẵn sàng"
• Hotfix production lẫn lộn với feature đang code dở
• Chẳng ai biết commit nào safe để deploy
• Release biến thành đêm thức trắng

Với Gitflow

Mỗi loại công việc có branch type riêng. Feature được isolate. Release được plan trước. Hotfix đi thẳng lên production mà không ảnh hưởng công việc đang làm.

5 Loại Branch

Gitflow dùng 2 branch vĩnh viễn và 3 loại branch tạm thời:

Cùng đi chi tiết từng loại nhé.

Branch Vĩnh Viễn

main — Branch Production

Branch này luôn phản ánh những gì đang chạy trên production. Mọi commit trên main đều là một release có thể deploy được.

Rules:

• Không bao giờ commit trực tiếp lên main
• Chỉ merge từ release/* hoặc hotfix/* branches
• Mỗi lần merge phải gắn version tag (ví dụ: v1.0, v1.2.1)

# Đừng bao giờ làm thế này:
git checkout main
git commit -m "quick fix"   # ❌ Đừng!
 
# Thay vào đó, luôn merge từ branch đúng:
git checkout main
git merge --no-ff release/1.0
git tag -a v1.0 -m "Release version 1.0"

develop — Branch Tích Hợp

Đây là nơi tất cả feature hoàn thành được tập hợp lại. Coi nó như khu vực staging cho "release tiếp theo".

Rules:

• Feature merge vào đây khi hoàn thành
• Luôn phải ở trạng thái chạy được (CI pass)
• Khi develop đủ ổn định, tạo release branch từ nó

Branch Tạm Thời

Feature Branches — Xây Dựng Tính Năng Mới

Mỗi feature mới có branch riêng. Giữ cho công việc của bạn tách biệt hoàn toàn với người khác.

Cách đặt tên: feature/login, feature/user-profile, feature/payment-api

Workflow đầy đủ:

# 1. Tạo feature branch từ develop
git checkout develop
git pull origin develop
git checkout -b feature/user-profile
 
# 2. Làm việc trên feature (nhiều commit thoải mái)
git add .
git commit -m "Add user profile page layout"
git commit -m "Add avatar upload functionality"
git commit -m "Add profile edit form"
 
# 3. Cập nhật branch (không bắt buộc nhưng nên làm)
git checkout develop
git pull origin develop
git checkout feature/user-profile
git merge develop    # Resolve conflict nếu có
 
# 4. Khi feature xong, merge về develop
git checkout develop
git merge --no-ff feature/user-profile
git push origin develop
 
# 5. Dọn dẹp
git branch -d feature/user-profile

Tại sao --no-ff? Flag --no-ff (no fast-forward) tạo merge commit ngay cả khi Git có thể fast-forward. Điều này giữ lại history rằng feature branch từng tồn tại, gom các commit liên quan lại, và giúp revert toàn bộ feature dễ dàng chỉ với một lệnh git revert.

Với fast-forward (mặc định):

* commit 3 (feature work)
* commit 2 (feature work)
* commit 1 (develop)

Với --no-ff:

*   Merge feature/user-profile into develop
|\
| * commit 3 (feature work)
| * commit 2 (feature work)
|/
* commit 1 (develop)

Phiên bản thứ hai cho thấy rõ feature bắt đầu và kết thúc ở đâu. Dễ hiểu hơn nhiều!

Release Branches — Chuẩn Bị Phát Hành

Khi develop đã có đủ feature cho version tiếp theo, bạn tạo release branch. Đây là giai đoạn "đóng băng" — không thêm feature mới, chỉ fix bug và bump version.

Cách đặt tên: release/1.0, release/2.1

Workflow đầy đủ:

# 1. Tạo release branch từ develop
git checkout develop
git checkout -b release/1.0
 
# 2. Bump version number
echo "1.0.0" > VERSION
git commit -am "Bump version to 1.0.0"
 
# 3. Fix bug nếu có (không thêm feature mới!)
git commit -m "Fix typo in login page"
git commit -m "Fix date formatting bug"
 
# 4. Khi sẵn sàng, merge vào main VÀ gắn tag
git checkout main
git merge --no-ff release/1.0
git tag -a v1.0 -m "Release version 1.0"
git push origin main --tags
 
# 5. Merge ngược về develop (để include các bug fix)
git checkout develop
git merge --no-ff release/1.0
git push origin develop
 
# 6. Dọn dẹp
git branch -d release/1.0

Tại sao merge vào cả main lẫn develop? Những bug fix bạn làm trong giai đoạn release freeze cần phải có trong develop nữa. Nếu không, bug sẽ xuất hiện lại ở release sau.

Hotfix Branches — Sửa Lỗi Khẩn Cấp Production

Production đang lỗi. User bị ảnh hưởng. Cần fix ngay — nhưng develop đang có feature code dở chưa sẵn sàng để ship.

Hotfix branch cho phép bạn vá production mà không đụng tới develop.

Cách đặt tên: hotfix/1.0.1, hotfix/fix-payment-crash

Workflow đầy đủ:

# 1. Tạo hotfix branch từ main (production)
git checkout main
git checkout -b hotfix/1.0.1
 
# 2. Fix bug nghiêm trọng
git commit -m "Fix payment processing crash on empty cart"
 
# 3. Bump patch version
echo "1.0.1" > VERSION
git commit -am "Bump version to 1.0.1"
 
# 4. Merge vào main và gắn tag
git checkout main
git merge --no-ff hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix: payment crash"
git push origin main --tags
 
# 5. Merge vào develop (để fix có trong các release tương lai)
git checkout develop
git merge --no-ff hotfix/1.0.1
git push origin develop
 
# 6. Dọn dẹp
git branch -d hotfix/1.0.1

Lưu ý quan trọng: Nếu đang có release/* branch, merge hotfix vào release branch thay vì develop. Fix sẽ đến develop khi release hoàn thành.

Bức Tranh Toàn Cảnh

Đây là cách tất cả branch type phối hợp trong một release cycle:

Thực Hành: Scenario Thực Tế

Cùng đi qua một sprint thực tế để thấy Gitflow hoạt động thế nào.

Tuần 1: Feature Development

# Alice làm user authentication
git checkout -b feature/auth develop
# ... code ...
 
# Bob làm dashboard
git checkout -b feature/dashboard develop
# ... code ...
 
# Cả hai merge khi xong
git checkout develop && git merge --no-ff feature/auth
git checkout develop && git merge --no-ff feature/dashboard

Tuần 2: Chuẩn Bị Release

# Team quyết định develop đã sẵn sàng cho v1.0
git checkout -b release/1.0 develop
 
# QA tìm thấy bug — fix trên release branch
git commit -m "Fix validation edge case"
 
# Trong khi đó, Charlie bắt đầu feature mới cho v1.1
git checkout -b feature/search develop
# Không ảnh hưởng gì tới release!

Tuần 2 (Thứ Năm): Hotfix Khẩn Cấp

# Hệ thống thanh toán trên production crash!
git checkout -b hotfix/0.9.1 main
git commit -m "Fix null pointer in payment handler"
 
# Merge hotfix vào main ngay lập tức
git checkout main && git merge --no-ff hotfix/0.9.1
git tag -a v0.9.1
 
# Merge vào release branch (không phải develop, vì đang có release)
git checkout release/1.0 && git merge --no-ff hotfix/0.9.1

Tuần 3: Ship It

# Release 1.0 sẵn sàng
git checkout main && git merge --no-ff release/1.0
git tag -a v1.0
 
# Sync ngược về develop
git checkout develop && git merge --no-ff release/1.0

Khi Nào Nên Dùng Gitflow?

Gitflow không phải lúc nào cũng là lựa chọn đúng. Chính tác giả cũng thêm note năm 2020 rằng model đơn giản hơn như GitHub Flow có thể phù hợp hơn cho nhiều team.

Dùng Gitflow Khi

✅ Software có version number rõ ràng (v1.0, v2.0)
✅ Cần support nhiều version trên production
✅ Đang build desktop app, library, CLI, hoặc API
✅ Có release process chính thức với QA stages
✅ Team có 5+ developer làm parallel features

Dùng Model Đơn Giản Hơn (GitHub Flow / Trunk-Based) Khi

✅ Deploy liên tục (nhiều lần mỗi ngày)
✅ Chỉ có một production version (web app, SaaS)
✅ Team nhỏ (1–4 developer)
✅ Có automated testing mạnh và CI/CD
✅ Muốn tối thiểu overhead về branching

So Sánh Nhanh

Lỗi Hay Gặp (và Cách Tránh)

1. Commit Trực Tiếp Lên main hoặc develop

# ❌ Sai
git checkout main
git commit -m "quick fix"
 
# ✅ Đúng — luôn dùng branch
git checkout -b hotfix/quick-fix main
git commit -m "Fix the issue"
git checkout main && git merge --no-ff hotfix/quick-fix

2. Quên --no-ff Khi Merge

# ❌ Sai — mất branch history
git merge feature/login
 
# ✅ Đúng — giữ lại branch history
git merge --no-ff feature/login

Pro tip: Config Git để luôn dùng no-ff:

git config --global merge.ff false

3. Thêm Feature Mới Trên Release Branch

Release branch chỉ để fix bug thôi. Nếu phát hiện cần feature mới, thêm vào develop cho release sau.

4. Quên Merge Ngược

Release và hotfix branch phải merge vào cả main lẫn develop. Quên merge về develop nghĩa là bug fix bị mất ở các release tương lai.

5. Feature Branch Sống Quá Lâu

Feature branch tồn tại hàng tuần sẽ biến thành ác mộng merge conflict. Giữ chúng ngắn:

• Merge develop vào feature branch thường xuyên
• Chia feature lớn thành các phần nhỏ hơn, có thể merge được
• Nhắm branch sống 3–5 ngày, không phải 3–5 tuần

Setup Gitflow

Cách 1: Thủ Công (Nên Dùng Khi Học)

Cứ follow branching convention bằng tay. Đây là cách chúng ta đã làm xuyên suốt bài viết. Nó giúp bạn hiểu chính xác chuyện gì đang xảy ra.

Cách 2: git-flow Extension

CLI tool git-flow tự động hóa các lệnh branching:

# Cài đặt
brew install git-flow-avh    # macOS
apt-get install git-flow     # Ubuntu/Debian
 
# Khởi tạo trong repo
git flow init
# Chấp nhận mặc định: main cho production, develop cho development
 
# Feature workflow
git flow feature start user-profile
# ... code ...
git flow feature finish user-profile
 
# Release workflow
git flow release start 1.0
# ... fix bug ...
git flow release finish 1.0
 
# Hotfix workflow
git flow hotfix start 1.0.1
# ... fix ...
git flow hotfix finish 1.0.1

Extension tự xử lý branching, merging, tagging, và cleanup. Nhưng mình khuyên nên làm thủ công trước cho đến khi bạn thoải mái với flow.

Gitflow Cheat Sheet

Feature

git checkout -b feature/X develop    # Bắt đầu
# ... code ...
git checkout develop                 # Kết thúc
git merge --no-ff feature/X
git branch -d feature/X

Release

git checkout -b release/X.Y develop  # Bắt đầu
# ... chỉ fix bug ...
git checkout main                    # Kết thúc
git merge --no-ff release/X.Y
git tag -a vX.Y
git checkout develop
git merge --no-ff release/X.Y
git branch -d release/X.Y

Hotfix

git checkout -b hotfix/X.Y.Z main   # Bắt đầu
# ... fix ...
git checkout main                    # Kết thúc
git merge --no-ff hotfix/X.Y.Z
git tag -a vX.Y.Z
git checkout develop
git merge --no-ff hotfix/X.Y.Z
git branch -d hotfix/X.Y.Z

Tổng Kết

1. Gitflow tách biệt mối quan tâm — production code, development, feature, release, và hotfix mỗi cái có làn riêng
2. main là thiêng liêng — luôn phản ánh production. Đừng bao giờ commit trực tiếp
3. develop là trung tâm — mọi feature đi qua đây trước khi lên production
4. --no-ff là bắt buộc — giữ lại branch history và giúp revert dễ dàng
5. Merge ngược là bắt buộc — release và hotfix branch merge vào cả main lẫn develop
6. Biết khi nào KHÔNG dùng — với continuous delivery web app, model đơn giản hơn như GitHub Flow thường tốt hơn

Hiểu Gitflow — kể cả khi team bạn dùng model khác — cho bạn mental framework vững chắc về cách code đi từ development đến production. Nó dạy bạn cách nghĩ về isolation, integration, và release management — những skill chuyển giao được sang bất kỳ branching strategy nào.

Đọc Thêm

• A Successful Git Branching Model — Bài viết gốc của Vincent Driessen
• GitHub Flow — Lựa chọn đơn giản hơn cho continuous delivery
• Trunk-Based Development — Model được team tốc độ cao ưa chuộng
• Atlassian Gitflow Workflow — Giải thích tuyệt vời khác với hình minh họa