Quy Ước Commit Message

Viết commit message rõ ràng là chìa khóa để quản lý dự án hiệu quả. Một commit message tốt giúp đồng đội (và chính bạn trong tương lai) nhanh chóng hiểu được mục đích và nội dung của từng thay đổi.

Chúng ta sẽ sử dụng các **tiền tố** chuẩn để phân loại commit, giúp lịch sử dự án gọn gàng và dễ tìm kiếm.

Cấu Trúc Cơ Bản của Commit Message

Một commit message lý tưởng thường có cấu trúc như sau:


<kiểu>: <mô tả ngắn gọn, không quá 50 ký tự>

[dòng trống]

[thân commit (tùy chọn): mô tả chi tiết hơn]
        

Ví dụ:


feat: thêm xác thực người dùng qua email và mật khẩu

Commit này giới thiệu một hệ thống xác thực mới cho phép người dùng đăng ký và đăng nhập bằng địa chỉ email và mật khẩu an toàn. Bao gồm:
- Endpoint đăng ký người dùng
- Endpoint đăng nhập với tạo token JWT
- Mã hóa mật khẩu sử dụng bcrypt
- Xử lý lỗi cơ bản cho thông tin đăng nhập không hợp lệ
        

Các Kiểu Commit Phổ Biến

feat: (Feature - Tính năng mới)

Khi bạn thêm một tính năng mới vào dự án.

Khi dùng:

  • Thêm chức năng, giao diện, hoặc bất kỳ điều gì mang lại khả năng mới cho ứng dụng.

Ví dụ:

  • feat: triển khai trang hồ sơ người dùng
  • feat: thêm nút chuyển đổi chế độ tối
  • feat: tích hợp Stripe cho thanh toán

fix: (Bug Fix - Sửa lỗi)

Khi bạn sửa một lỗi nào đó.

Khi dùng:

  • Khắc phục lỗi khiến ứng dụng hoạt động không đúng hoặc gặp sự cố.

Ví dụ:

  • fix: sửa lỗi vòng lặp vô hạn khi lấy dữ liệu
  • fix: khắc phục vấn đề styling trên giao diện di động
  • fix: ngăn chặn lỗ hổng XSS trong phần bình luận

docs: (Documentation - Tài liệu)

Khi bạn chỉ thay đổi về tài liệu (documentation).

Khi dùng:

  • Cập nhật README, thêm bình luận code, sửa lỗi chính tả trong tài liệu, v.v.

Ví dụ:

  • docs: cập nhật README với hướng dẫn cài đặt
  • docs: thêm bình luận vào thuật toán phức tạp
  • docs: sửa lỗi chính tả trong CONTRIBUTING.md

style: (Code Style - Phong cách code)

Khi bạn thay đổi liên quan đến định dạng code, không ảnh hưởng đến logic.

Khi dùng:

  • Sửa lỗi định dạng, khoảng trắng, dấu chấm phẩy, tuân thủ linter, v.v.

Ví dụ:

  • style: định dạng code với Prettier
  • style: thêm dấu chấm phẩy còn thiếu
  • style: điều chỉnh thụt lề để dễ đọc

refactor: (Refactoring - Tái cấu trúc)

Khi bạn thay đổi cấu trúc code mà không sửa lỗi hay thêm tính năng.

Khi dùng:

  • Cải thiện cấu trúc code, tối ưu hiệu suất, làm cho code dễ đọc hơn mà không thay đổi hành vi bên ngoài.

Ví dụ:

  • refactor: tái cấu trúc các route API để tổ chức tốt hơn
  • refactor: tách logic xác thực vào tiện ích riêng
  • refactor: đổi tên biến để rõ ràng hơn

test: (Tests - Kiểm thử)

Khi bạn thêm, sửa đổi hoặc xóa các bài kiểm thử.

Khi dùng:

  • Viết test mới, sửa lỗi trong test hiện có, hoặc xóa test không còn cần thiết.

Ví dụ:

  • test: thêm unit test cho dịch vụ người dùng
  • test: sửa lỗi flaky test tích hợp
  • test: loại bỏ các test case đã lỗi thời

chore: (Chores - Công việc lặt vặt)

Các thay đổi nhỏ, bảo trì không liên quan trực tiếp đến code ứng dụng.

Khi dùng:

  • Cập nhật thư viện, thay đổi cấu hình build, dọn dẹp file không cần thiết, v.v.

Ví dụ:

  • chore: cập nhật các dependency
  • chore: cấu hình husky hooks
  • chore: xóa các tài sản không sử dụng

Các Kiểu Khác (Ít phổ biến hơn)

Tại Sao Nên Tuân Thủ?

Việc áp dụng các quy ước này có thể mất một chút thời gian ban đầu, nhưng lợi ích về lâu dài chắc chắn sẽ rất đáng giá cho dự án của bạn!