Git workflow 2026: Trunk-based vs Git Flow vs GitHub Flow cho team VN 2-5 người

Team VN nhỏ 2-5 người thường sai ở 2 hướng: (1) Copy Git Flow từ tutorial năm 2015 mà không hiểu trade-off, kết quả: branch quá nhiều, merge conflict liên tục. (2) Không có quy ước, commit thẳng main, push force, không review code, bug xuất hiện.

Bài này hướng dẫn chọn workflow đúng theo tốc độ release và loại sản phẩm của team bạn, không theo trend.

Git Flow (Vincent Driessen, 2010): - 5 loại branch: main (production), develop (integration), feature/*, release/*, hotfix/*. - Flow: dev branch từ develop → PR về develop → tạo release/* → test → merge về main + tag version + merge back develop. - Phù hợp: software có versioning rõ ràng (v1.0, v1.1), maintain multiple version support simultaneously.

GitHub Flow (GitHub, 2011): - 2 loại branch: main + feature/*. - Flow: branch từ main → PR về main → review → merge → deploy ngay. - Phù hợp: web app + SaaS có continuous deployment, 1 version active.

Trunk-based (Paul Hammant, popular 2019+): - Chủ yếu main branch + feature branch rất ngắn (< 2 ngày) hoặc trực tiếp commit main. - Flow: commit nhỏ + thường xuyên vào main. Feature chưa hoàn thành → ẩn sau feature flag. Deploy main tự động hằng ngày. - Phù hợp: team mature có CI/CD + feature flag + monitoring tốt.

Trunk-based (TBD) là workflow được 84% team top theo DORA Report 2024 (State of DevOps). Philosophy: branch càng ngắn càng ít conflict.

Rules căn bản: 1. Commit vào main (hoặc PR với branch < 2 ngày). Không có long-lived branch như develop/release. 2. Mỗi commit phải pass CI (build + test + lint). 3. Feature chưa xong → dùng feature flag để ẩn khỏi user, code vẫn merge vào main. 4. Deploy main liên tục (hoặc ít nhất daily). 5. Không có 'big bang release' — incremental, reversible.

Ưu điểm: - Ít conflict — branch ngắn, rebase thường xuyên. - Feedback nhanh — code lên production trong ngày, phát hiện bug sớm. - Less code review overhead — PR nhỏ dễ review (< 200 dòng) vs Git Flow PR lớn 1000+ dòng. - Git history sạch — linear, dễ bisect khi debug.

Nhược điểm + yêu cầu: - CI/CD phải automate 100%: test, lint, build, deploy. Setup 1-2 tuần đầu tốn công. - Feature flag system: LaunchDarkly ($$$), Unleash (open-source), PostHog Feature Flags (free tier). Team cần tool quản flag. - Monitoring + rollback: deploy liên tục cần observability (Sentry, Datadog). Nếu deploy fail → rollback flag + fix-forward trong 15 phút. - Code review culture: PR merge nhanh → reviewer phải xem trong giờ, không chờ 2-3 ngày.

GitHub Flow là option default cho team không muốn vừa lớn vừa strict như Trunk-based. Phù hợp nhất cho team VN 2-5 người làm web app.

Rules: 1. main luôn deployable. Không commit thẳng main. 2. Tạo branch từ main, tên descriptive: fix-login-race-condition, add-payment-webhook. 3. Commit + push thường xuyên (daily). 4. Mở PR sớm (draft), không chờ feature xong mới open. 5. Code review bắt buộc, ít nhất 1 approval. 6. Pass CI (test + lint + build). 7. Merge → deploy main tự động. 8. Feature branch delete sau merge.

Branch naming convention khuyến nghị VN team: - feat/user-profile-avatar — tính năng mới. - fix/login-timeout — bug fix. - refactor/api-error-handling — refactor. - docs/readme-deployment — docs. - chore/upgrade-next-16 — bảo trì. - hotfix/payment-crash-prod — khẩn cấp prod.

Commit message convention (Conventional Commits): ``` feat(auth): add OAuth2 Google login fix(payment): resolve race condition in webhook docs(readme): update deployment instructions refactor(api): extract error handler middleware ```

Tool generate commit message bằng AI: Copilot (git cm với extension), hoặc dùng Claude Code claude-code commit. Xem bài AI code assistant 2026 cho setup.

CI setup tối thiểu (GitHub Actions, miễn phí cho repo public + 2000 phút/tháng private): ```yaml name: CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: '22', cache: 'npm' } - run: npm ci - run: npm run lint - run: npm test - run: npm run build ```

Git Flow không lỗi thời — chỉ là đặt đúng chỗ. Khi nào vẫn nên dùng:

1. Library/SDK có versioning: - VD: team làm React UI library, release v1.0, v1.1, v2.0. - Cần maintain support v1.x khi v2.x phát triển. - Branch support/1.x để backport bug fix.

2. Mobile app với store release cycle: - App Store/Play Store có review time 24-72h. - Release candidate cần freeze 3-5 ngày test. - Git Flow release/* fit: code trong release branch freeze, develop tiếp tục nhận feature mới.

3. Desktop app hoặc embedded software: - Release 1-2 lần/năm. - User download version cụ thể. - Hotfix cho old version mà không affect current dev.

4. Enterprise với compliance strict: - Regulated industry (banking, healthcare) yêu cầu audit log release. - Release branch = 'được duyệt bởi QA/security team'. - Git Flow tạo boundary rõ cho auditor.

Regardless workflow, team VN nên setup branch protection rules để tránh accident:

GitHub Settings → Branches → Add rule cho main: - ✅ Require pull request before merging. - ✅ Require at least 1 approval. - ✅ Dismiss stale approvals when new commits pushed. - ✅ Require status checks to pass (CI tests). - ✅ Require branches to be up to date before merging. - ✅ Require conversation resolution before merging. - ✅ Do not allow force push. - ✅ Require signed commits (advanced).

Merge strategy khuyến nghị: - Squash and merge (default tốt nhất cho team nhỏ): gộp commit feature branch thành 1 commit trên main. Git history sạch. - Rebase and merge: giữ commit nhưng linear. Fit advanced team. - Merge commit: tránh — tạo diamond history rối.

Auto-delete branch sau merge: Settings → General → Automatically delete head branches → ON.

CODEOWNERS file (nếu team > 3 người): ``` # .github/CODEOWNERS /backend/ @senior-backend-dev /frontend/ @senior-frontend-dev /docs/ @product-manager ``` PR touch file → auto-assign reviewer tương ứng.

Bước 1: Team bao nhiêu người? - 1 người (solo): không cần workflow formal. Commit main direct, CI test auto. Dùng GitHub Flow nếu muốn practice PR. - 2-10 người: bước 2. - 10+ người: hầu hết Trunk-based hoặc GitHub Flow. Git Flow cho special case.

Bước 2: Deploy bao lâu 1 lần? - Multiple lần/ngày: Trunk-based (yêu cầu CI/CD + feature flag). - 1-3 lần/tuần: GitHub Flow. Đơn giản, ít overhead. - 1-4 tuần: GitHub Flow với release tag hoặc Git Flow simplified. - Monthly hoặc lâu hơn: Git Flow đầy đủ hoặc release branch strategy.

Bước 3: Loại sản phẩm? - Web app/SaaS/API: GitHub Flow hoặc Trunk-based. - Mobile app: GitHub Flow + release tag (hoặc Git Flow simplified với release/*). - Library/SDK: Git Flow (có support/* branches). - Desktop/Embedded: Git Flow đầy đủ.

Để dev team VN hiệu quả hơn, tham khảo thêm Docker Desktop vs Colima vs OrbStack 2026 cho local dev environment và setup Mac M4 cho dev fullstack.