3.11 — 9. Conventional Commits
Mục tiêu bài học
- Nắm được ý chính của bài và mối liên hệ với module.
- Áp dụng được kiến thức vào bối cảnh CRM/.NET backend.
- Sẵn sàng chuyển sang bài kế tiếp với nền tảng chắc chắn.
Nội dung bài học
3.11.1 — Tại sao cần chuẩn hóa commit message?
Một lịch sử commit như thế này hoàn toàn vô nghĩa:
fix
aaa
test123
cuoi cung xong roi
update
Trong khi đây là lịch sử commit của team chuyên nghiệp:
feat(crm): add customer search by name and phone number
fix(crm): resolve null reference when customer has no address
refactor(auth): extract token validation to middleware
test(crm): add unit tests for CustomerService.SearchAsync
docs(api): update Swagger description for customer endpoints
Commit message tốt giúp: đồng đội hiểu thay đổi không cần đọc code, tự động tạo CHANGELOG, dễ git bisect khi tìm commit gây ra bug.
3.11.2 — Format chuẩn Conventional Commits
<type>(<scope>): <mô tả ngắn gọn>
[body tùy chọn — giải thích tại sao, không phải cái gì]
[footer tùy chọn — BREAKING CHANGE, Refs #123]
Các type phổ biến:
| Type | Ý nghĩa | Ví dụ cho CRM |
|---|---|---|
feat | Tính năng mới | feat(crm): add customer import from CSV |
fix | Sửa bug | fix(crm): customer search returns 500 on empty query |
refactor | Cải thiện code | refactor(crm): extract search logic to specification pattern |
test | Thêm/sửa test | test(crm): add integration tests for CustomerController |
docs | Tài liệu | docs(crm): add API usage examples in Swagger |
chore | Công việc bảo trì | chore: update NuGet packages to latest stable |
perf | Cải thiện hiệu năng | perf(crm): add index on customer email column |
Breaking change — khi thay đổi phá vỡ API hiện tại:
git commit -m "feat(crm)!: rename GetCustomer to GetCustomerById
BREAKING CHANGE: API endpoint /api/customers/{id} now requires authentication header"
3.11.3 — Cấu hình commitlint để enforce chuẩn (tuỳ chọn)
Trong dự án có thể dùng commitlint + husky để tự động reject commit không đúng format:
npm install --save-dev @commitlint/cli @commitlint/config-conventional husky
Bài tập áp dụng
- Tóm tắt bài học bằng ngôn ngữ của bạn.
- Liên hệ nội dung với một tình huống thực tế trong dự án.
- Đề xuất một cải tiến cụ thể sau khi học bài này.
Tự kiểm tra
- Bạn có thể giải thích lại nội dung chính trong 2 phút không?
- Bạn có ví dụ áp dụng thực tế chưa?
- Bạn biết bước tiếp theo cần học/triển khai là gì không?
Kết luận
Hoàn thành bài này giúp bạn có góc nhìn đầy đủ hơn trước khi đi tiếp trong module.
Điều hướng
- Bài trước: 3.10 — 8. Debugging Workflow
- Bài tiếp theo: 3.12 — Mở rộng và đào sâu
- Về module: Trang mục lục