Tuần 2 - Ngày 1: Workflow Models — Chọn Chiến Lược Đúng Cho Team

Mục tiêu học tập

• Hiểu Git Flow, GitHub Flow, GitLab Flow, Trunk-based Development
• Biết khi nào chọn workflow nào dựa trên team size và release cadence
• So sánh trade-off của từng workflow

---

1. Tại sao cần chọn workflow?

Git cho phép làm nhiều thứ, nhưng team cần đồng thuận về một workflow. Không có workflow duy nhất đúng — mỗi cái tối ưu cho context khác nhau.

Câu hỏi cần trả lời khi chọn:
1. Release cadence: release nhiều lần/ngày hay mỗi vài tuần?
2. Team size: 2 người hay 50 người?
3. Versioning: hỗ trợ multiple versions song song không?
4. CI/CD maturity: tự động test và deploy không?
5. Hotfix policy: có cần fix nhanh prod không cần deploy toàn bộ?

---

2. Git Flow (Vincent Driessen, 2010)

Cấu trúc branches

Các branches chính

Lifecycle Git Flow

# Feature development
git switch develop
git switch -c feature/user-notifications
# ... làm việc ...
git switch develop
git merge --no-ff feature/user-notifications
git branch -d feature/user-notifications

# Chuẩn bị release
git switch develop
git switch -c release/1.4.0
# Chỉ bugfix trong release branch, KHÔNG thêm feature mới
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release version 1.4.0"
git switch develop
git merge --no-ff release/1.4.0   # merge bugfix về develop
git branch -d release/1.4.0

# Hotfix trên production
git switch main
git switch -c hotfix/payment-null-deref
# ... fix ...
git switch main
git merge --no-ff hotfix/payment-null-deref
git tag -a v1.4.1
git switch develop
git merge --no-ff hotfix/payment-null-deref   # đừng quên merge vào develop
git branch -d hotfix/payment-null-deref

Khi nào dùng Git Flow

Phù hợp:
✓ Release theo lịch (mỗi sprint, mỗi tháng)
✓ Hỗ trợ nhiều version song song (v1.x, v2.x)
✓ Desktop apps, mobile apps, thư viện (lib/SDK)
✓ Team lớn cần quản lý chặt

Không phù hợp:
✗ Web apps deploy liên tục (CD)
✗ Team nhỏ (<5 người) — quá nhiều overhead
✗ Startup cần move fast

---

3. GitHub Flow (GitHub, 2011)

Workflow đơn giản hơn rất nhiều. Chỉ có main và feature branches.

Nguyên tắc cốt lõi

1. main luôn deployable
2. Mọi thứ đều làm trên branch riêng
3. Push thường xuyên, mở PR sớm
4. Review trên PR
5. Deploy từ branch (test) trước khi merge
6. Merge vào main → deploy production ngay

Lifecycle GitHub Flow

# Full GitHub Flow cycle
git switch main && git pull
git switch -c feature/search-autocomplete

# ... làm việc, commit nhiều lần ...
git push -u origin feature/search-autocomplete

# Mở PR trên GitHub → review → CI chạy
# Deploy feature branch lên staging để test

# Sau khi approve
# → Merge PR (squash hoặc merge commit)
# → Tự động deploy main lên production

# Dọn dẹp local
git switch main && git pull
git branch -d feature/search-autocomplete

Khi nào dùng GitHub Flow

Phù hợp:
✓ Web apps với Continuous Deployment
✓ Team nhỏ đến vừa (2-20 người)
✓ Startup, SaaS
✓ Khi main luôn reflect production

Không phù hợp:
✗ Cần maintain multiple versions
✗ Release có cửa sổ deployment (maintenance window)
✗ Regulatory compliance yêu cầu cần test giai đoạn dài

---

4. GitLab Flow

GitLab Flow là middle ground: đơn giản như GitHub Flow nhưng có thêm environment branches.

Với environment branches

Với release branches (khi cần versioning)

# Không có separate develop branch
# Feature → main → cherry-pick hoặc merge sang release branches

# Tạo release branch khi cần
git switch main
git switch -c release/2.3

# Hotfix: fix trên main trước
git switch main
git commit -m "fix: critical security patch"

# Backport sang release
git switch release/2.3
git cherry-pick <hash-of-fix>

---

5. Trunk-Based Development (TBD)

Tất cả mọi người commit thẳng lên main (trunk), thay vì dùng long-lived branches.

Hai biến thể

Yêu cầu để TBD hoạt động

Bắt buộc:
✓ Feature flags (feature toggles) — tắt incomplete features ở production
✓ CI/CD rất mạnh: test chạy < 10 phút, pass → auto deploy
✓ Pair programming hoặc code review nhanh
✓ Branches sống < 1-2 ngày

Kỹ thuật hỗ trợ:
- Branch by abstraction (refactor lớn mà không lock branch)
- Strangler fig pattern (migrate dần)

# Feature flag pattern với TBD
// config/features.ts
export const FEATURES = {
  newSearchAlgorithm: process.env.FEATURE_NEW_SEARCH === 'true',
  betaPaymentFlow: process.env.FEATURE_BETA_PAYMENT === 'true',
};

// Trong code
if (FEATURES.newSearchAlgorithm) {
  return searchV2(query);   // code incomplete, disabled by flag
}
return searchV1(query);     // luôn chạy ở production

Khi nào dùng TBD

Phù hợp:
✓ Google, Facebook, Netflix scale (CI/CD mature)
✓ Team có experience cao
✓ Microservices với independent deploy
✓ Web services deploy nhiều lần/ngày

Không phù hợp:
✗ Team chưa có CI/CD tốt
✗ Outsourced development với contributors chất lượng không đều
✗ Cần maintain multiple versions

---

6. So sánh tổng hợp

Decision tree nhanh

---

Câu hỏi ôn tập

1. Git Flow có bao nhiêu loại long-lived branches? Nêu tên và vai trò của từng loại.

   Xem đáp án

   Git Flow có 2 long-lived branches: main (code production, luôn deployable, được tag version) và develop (integration branch, nơi feature branches merge vào, là source cho release branches). Ngoài ra còn 3 loại short-lived branches: feature/*, release/*, hotfix/*.

2. Tại sao GitHub Flow yêu cầu main luôn phải deployable?

   Xem đáp án

   GitHub Flow không có develop/staging branch riêng — main là duy nhất và trực tiếp deploy production. Nếu main không deployable, bất kỳ hotfix nào cũng không thể deploy ngay. Yêu cầu này buộc team: (1) chỉ merge PR sau khi CI pass và code review approve, (2) deploy từ branch trước khi merge, (3) maintain culture of "always green main".

3. Feature flags trong TBD giải quyết vấn đề gì mà branching không giải quyết được?

   Xem đáp án

   Feature flags cho phép deploy code của một feature chưa hoàn chỉnh lên production mà không bật cho users — code tồn tại trong codebase nhưng disabled. Branching không thể giải quyết được vì: long-lived feature branch cuối cùng phải merge, và càng để lâu càng nhiều conflict. Feature flags tách "deploy" khỏi "release" — team có thể deploy thường xuyên (TBD) mà không lo expose incomplete features.

4. Startup SaaS với 5 developer, deploy 3 lần/ngày nên dùng workflow nào? Tại sao?

   Xem đáp án

   GitHub Flow là lựa chọn tốt nhất. Lý do: (1) Team nhỏ — không cần overhead của Git Flow (develop, release branches). (2) Deploy liên tục (CD) — GitHub Flow được thiết kế cho Continuous Deployment từ main. (3) Đơn giản — ít branches = ít cognitive overhead = move fast. (4) Nếu CI/CD đã trưởng thành hơn và team muốn, có thể migrate sang Trunk-based Development.

5. Khi nào nên chọn GitLab Flow thay vì Git Flow?

   Xem đáp án

   GitLab Flow phù hợp khi: (1) Cần environment gates (staging → production), tức là code phải pass từng environment trước khi promote — không muốn deploy thẳng từ main như GitHub Flow. (2) Cần versioning/multi-version support nhưng Git Flow quá phức tạp. (3) Web app với deployment pipeline có nhiều bước nhưng vẫn muốn release cadence linh hoạt hơn Git Flow truyền thống.

Bài tập thực hành

# Mô phỏng Git Flow cho một feature nhỏ
mkdir workflow-lab && cd workflow-lab
git init
git config user.name "Test" && git config user.email "test@test.com"

# Setup: tạo main và develop
echo "v1.0.0" > version.txt
git add . && git commit -m "chore: initial commit"
git switch -c develop
echo "develop" > develop.txt
git add . && git commit -m "chore: setup develop branch"

# Feature branch
git switch -c feature/user-search
echo "search feature" > search.js
git add . && git commit -m "feat: add user search"

# Merge về develop (--no-ff như Git Flow)
git switch develop
git merge --no-ff feature/user-search -m "feat: merge user search feature"
git branch -d feature/user-search

# Release branch
git switch -c release/1.1.0
echo "1.1.0" > version.txt
git add . && git commit -m "chore: bump version to 1.1.0"

# Merge vào main
git switch main
git merge --no-ff release/1.1.0 -m "release: version 1.1.0"
git tag -a v1.1.0 -m "Release 1.1.0"

# Merge về develop
git switch develop
git merge --no-ff release/1.1.0
git branch -d release/1.1.0

# Xem lịch sử
git log --oneline --graph --all

Tài liệu tham khảo chính thức

• A successful Git branching model (Vincent Driessen)
• GitHub Flow
• GitLab Flow
• Trunk-Based Development

---

Tiếp theo: Ngày 2 — Pull Request và Interactive Rebase