Hãy tưởng tượng bạn đang code một feature mới, đến 90% thì... máy bị tắt nguồn đột ngột. Hoặc bạn vừa merge code của đồng nghiệp, và đột nhiên toàn bộ hệ thống báo lỗi không rõ nguyên nhân. Hay đơn giản hơn: bạn cần biết ai đã sửa dòng code này 3 tháng trước và tại sao họ lại làm vậy?
Đây chính là lý do Version Control (Quản lý phiên bản) và CI/CD (Tích hợp và Triển khai Liên tục) trở thành kỹ năng bắt buộc của mọi kỹ sư phần mềm. Không phải để "sang chảnh", mà để sống sót trong môi trường làm việc nhóm và production thực tế.
Nhiều người nghĩ Git chỉ là công cụ backup code lên cloud. Thực tế, Git là một distributed version control system với cấu trúc dữ liệu tinh vi: DAG - Directed Acyclic Graph.
Vậy DAG là gì?
E---F---G (feature-branch)
/
A---B---C---D (main)
\
H---I (hotfix-branch)
Mỗi commit là một snapshot đầy đủ của codebase tại thời điểm đó, không chỉ là "diff" so với version trước. Đây là điểm khác biệt lớn giữa Git và các hệ thống cũ như SVN.
Tại sao điều này quan trọng?
git commitBa vùng lưu trữ của Git:
Workflow cơ bản:
Working Directory → git add → Staging Area → git commit → Repository
Tại sao cần Staging Area?
Nhiều người thắc mắc: "Tại sao không commit trực tiếp mà phải git add trước?"
→ Staging Area cho phép bạn kiểm soát chính xác những gì được commit:
git add -p để chọn từng hunk (đoạn code) trong một fileVí dụ thực tế:
# Bạn đang fix bug và đồng thời refactor code
git add src/fix-payment-bug.js # Chỉ add file fix bug
git commit -m "Fix payment calculation error"
git add src/refactor-utils.js # Commit refactor riêng
git commit -m "Refactor: extract common utilities"
GitFlow được Vincent Driessen giới thiệu năm 2010, phù hợp với release-based development (phát hành theo từng version).
Các nhánh trong GitFlow:
Workflow:
1. Tạo feature branch từ develop
git checkout -b feature/user-authentication develop
2. Code và commit
git commit -am "Implement login API"
3. Merge về develop
git checkout develop
git merge --no-ff feature/user-authentication
4. Khi sẵn sàng release, tạo release branch
git checkout -b release/1.2.0 develop
5. Bug fixes trên release branch, sau đó merge vào main và develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0
Ưu điểm:
Nhược điểm:
Trunk-based là chiến lược của các công ty tech lớn (Google, Facebook) và startup cần tốc độ.
Nguyên tắc cốt lõi:
Workflow:
1. Code trực tiếp trên main (hoặc short-lived branch)
git checkout main
git pull
git checkout -b feature/quick-fix
2. Commit nhỏ, thường xuyên
git commit -m "Add user model"
git commit -m "Add user controller"
3. Merge về main trong vòng vài giờ/1 ngày
git checkout main
git merge feature/quick-fix
git push origin main
Feature Flags ẩn code chưa xong:
if (featureFlags.newCheckout) {
// Code mới, chưa stable
return <NewCheckoutFlow />;
} else {
// Code cũ, đã stable
return <OldCheckoutFlow />;
}
Khi feature mới ready, chỉ cần flip flag từ false → true, không cần deploy lại code.
Ưu điểm:
Nhược điểm:
| Tiêu chí | GitFlow | Trunk-based |
|---|---|---|
| Phù hợp cho | Release-based, team lớn | Continuous delivery, startup |
| Tốc độ release | Chậm (vài tuần/tháng) | Nhanh (nhiều lần/ngày) |
| Complexity | Cao | Thấp |
| Merge conflicts | Nhiều | Ít |
| Yêu cầu CI/CD | Trung bình | Cao |
Rule of thumb:
Code review không chỉ là "tìm bug" - đó là cơ hội knowledge sharing, maintain code quality, và mentor junior developers.
1. Developer tạo PR (Pull Request)
git checkout -b feature/add-payment-gateway
# ... code code code ...
git push origin feature/add-payment-gateway
# Tạo PR trên GitHub/GitLab
2. PR phải include:
3. Reviewer checklist:
✅ Functionality: Code có làm đúng yêu cầu không?
✅ Tests: Có unit/integration tests đầy đủ không?
✅ Edge cases: Xử lý các trường hợp ngoại lệ chưa?
✅ Performance: Có query N+1, memory leak, hoặc inefficient algorithms không?
✅ Security: Có lỗ hổng SQL injection, XSS, hardcoded secrets không?
✅ Code style: Tuân thủ coding conventions của team không?
✅ Naming: Biến/hàm có tên dễ hiểu không? (getUserById tốt hơn getData)
✅ Documentation: Code phức tạp có comment giải thích không?
Cho Reviewer:
✅ Nitpick rõ ràng: Nếu comment không critical, tag [nit] để author biết có thể bỏ qua
[nit] Có thể đổi tên biến `temp` thành `filteredUsers` cho dễ hiểu hơn
✅ Khen ngợi code tốt: Không chỉ chỉ ra lỗi
Nice refactoring! Việc extract helper function này làm code clean hơn nhiều 👍
✅ Hỏi thay vì ra lệnh:
❌ "Đổi logic này lại"
✅ "Bạn có cân nhắc cách tiếp cận X không? Nó có thể handle edge case Y tốt hơn"
✅ Chỉ ra vấn đề + đề xuất giải pháp:
Issue: Function này có cyclomatic complexity cao (15), khó test
Suggestion: Có thể extract validation logic ra một function riêng?
Cho Author:
✅ Không defensive: Code review không phải tấn công cá nhân
✅ Giải thích reasoning: Nếu reviewer không hiểu, có thể code chưa đủ clear
✅ Tách commit nhỏ: Một PR khổng lồ 50 files = nightmare cho reviewer
✅ Respond mọi comment: Ngay cả khi chỉ là "Fixed" hoặc "Good point"
Một commit message tốt giúp team hiểu tại sao thay đổi này xảy ra, không chỉ cái gì thay đổi (code diff đã show rồi).
Conventional Commits format:
<type>(<scope>): <subject>
<body>
<footer>
Types phổ biến:
feat: Tính năng mớifix: Sửa bugrefactor: Sửa code không thay đổi behaviordocs: Cập nhật documentationtest: Thêm/sửa testschore: Công việc maintenance (update dependencies, v.v.)Ví dụ tốt:
feat(auth): add OAuth 2.0 social login
- Integrate Google and Facebook OAuth providers
- Add user profile sync from social accounts
- Store OAuth tokens securely in encrypted format
Closes #123
Ví dụ tệ:
update code (quá mơ hồ)
fix bug (bug nào?)
asdfasdf (vô nghĩa)
Mục tiêu: Phát hiện lỗi sớm nhất có thể bằng cách integrate code thường xuyên và test tự động.
CI Pipeline điển hình:
1. Developer push code
↓
2. CI server (Jenkins/GitHub Actions) trigger
↓
3. Checkout code
↓
4. Install dependencies (npm install, pip install)
↓
5. Run linter (eslint, pylint)
↓
6. Run unit tests
↓
7. Run integration tests
↓
8. Build application (compile, bundle)
↓
9. Success ✅ hoặc Fail ❌
GitHub Actions example:
name: CI Pipeline
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '18'
- run: npm install
- run: npm run lint
- run: npm test
- run: npm run build
Lợi ích CI:
Mục tiêu: Deploy code lên production tự động sau khi pass tất cả tests.
CD Pipeline:
1. CI pipeline pass ✅
↓
2. Build Docker image
↓
3. Push image lên registry
↓
4. Deploy lên staging environment
↓
5. Run smoke tests (kiểm tra các chức năng core)
↓
6. Deploy lên production (hoặc chờ manual approval)
Deployment Strategies:
1. Blue-Green Deployment
2. Canary Deployment
3. Rolling Deployment
✅ Fail fast: Nếu linter fail, đừng chạy test nữa (waste time)
✅ Parallel jobs: Chạy unit test và integration test song song để giảm thời gian
✅ Caching dependencies: Cache node_modules, venv để không phải install lại mỗi lần
✅ Secrets management: Không bao giờ hardcode API keys - dùng environment variables
✅ Notifications: Slack/Email thông báo khi pipeline fail
✅ Rollback plan: Luôn có chiến lược rollback nếu deployment fail
Git không chỉ là "save file trên cloud", mà là nền tảng cho collaboration và code history management. Hiểu DAG, branching strategies, và code review giúp bạn làm việc hiệu quả trong team.
CI/CD biến việc deploy từ "nghi lễ phức tạp" thành quy trình tự động. Bạn focus vào viết code, còn lại để CI/CD lo.
Skill progression:
git add, commit, push, pullAction items:
Trong bài tiếp theo, chúng ta sẽ đi sâu vào Machine Learning Concepts - nơi những nguyên lý toán học gặp gỡ thực tiễn ứng dụng AI.
Bài viết thuộc series "From Zero to AI Engineer" - Module 3: Implementation & Quality Assurance