Trong quy trình phát triển phần mềm hiện đại, việc đánh số phiên bản (versioning) thủ công luôn là một vấn đề khó khăn. Giải pháp cho vấn đề này chính là kết hợp Semantic Versioning (SemVer) với Conventional Commits. Bài viết này sẽ hướng dẫn cách viết Git Commit sao cho hệ thống tự động nhận diện và tăng version chính xác.
- Semantic Versioning là gì?
Semantic Versioning là quy chuẩn đặt tên phiên bản phổ biến nhất thế giới, có dạng X.Y.Z (Ví dụ: 1.5.3). Ý nghĩa của từng con số như sau:
MAJOR (X – Số đầu tiên): Phiên bản thay đổi lớn.
- Ý nghĩa: Có thay đổi làm phá vỡ tính tương thích ngược (Breaking Changes). Code cũ có thể không chạy được nếu nâng cấp lên bản này.
- Ví dụ:
1.0.0->2.0.0 - Tuy nhiên ở một số dự án, đặc biệt là các dự án về game thì sự thay đổi về số này chủ yếu theo năm (ví dụ: 2025 là 1.0.0, 2026 là 2.0.0)
MINOR (Y – Số thứ hai): Phiên bản tính năng.
- Ý nghĩa: Thêm tính năng mới nhưng vẫn tương thích ngược. Người dùng cập nhật lên vẫn dùng bình thường.
- Ví dụ:
1.5.0->1.6.0
PATCH (Z – Số cuối cùng): Phiên bản vá lỗi, có thể liên quan đến backend hoặc frontend, không thêm tính năng mới.
- Ý nghĩa: Sửa lỗi (Bug fix) và tương thích ngược. Không có tính năng mới.
- Ví dụ:
1.5.3->1.5.4
2. Cách viết Commit đúng cách
Để có thể tăng version tự động thì cần phải biết cách viết Commit đúng.
Trường hợp 1: Tăng PATCH (sửa lỗi, hot fix)
Khi dev sửa một lỗi nhỏ, tối ưu code, hoặc cập nhật tài liệu mà không làm thay đổi các tính năng chính, chúng ta có thể dùng các từ chủ đạo như “fix”, “update”… Bằng cách này, hệ thống sẽ nhận diện được và tăng số cuối cùng (Z). Những đợt cập nhật này diễn ra rất thường xuyên
Ví dụ: git commit -m “fix: sửa lỗi nút đăng nhập không phản hồi trên Safari”
Trường hợp 2: Tăng MINOR (Thêm hoặc lược bỏ tính năng)
Khi thêm hoặc bỏ một chức năng, việc này phải không làm hỏng code cũ, không gây xung đột trong trải nghiệm người dùng. Trong trường hợp này ta sẽ dùng từ khóa “feat:”, hệ thống sẽ tăng số ở giữa và reset số cuối về 0 (1.0.6-> 1.1.0).
Ví dụ: git commit -m “feat: thêm chức năng đăng nhập bằng Google”.
Trường hợp 3: Tăng MAJOR (Thay đổi lớn – Breaking Change)
Đây là đợt thay đổi lơn và quan trọng. Khi dev thay đổi cấu trúc dữ liệu, xóa API cũ, hoặc làm những việc khiến dev khác bắt buộc phải sửa code của họ mới dùng tiếp được. Nhưng đợt thay đổi này diễn ra rất ít, vài tháng hoặc vài năm mới có một lần. Chúng ta sẽ dùng từ khóa “!” (ngay sau type) hoặc “BREAKING CHANGE”, hệ thống sẽ tăng số đầu tiên và reset 2 số sau (1.5.3->2.0.0)
Ví dụ: git commit -m “feat!: thay đổi cấu trúc response API user (xóa trường age)” ; git commit -m “fix!: nâng cấp version thư viện core, không hỗ trợ Node 12 nữa” ; git commit -m “BREAKING CHANGE: Update Ubuntu”
3. Kết luận
Việc tuân thủ quy tắc viết commit không chỉ giúp hệ thống CI/CD tự động hóa việc đánh version mà còn giúp lịch sử Git của dự án trở nên rõ ràng, dễ đọc và chuyên nghiệp hơn.
Hãy bắt đầu thói quen viết feat:, fix: thay vì những commit vô nghĩa như update code hay fixed bug.