Vấn đề

Khi còn đi học, có rất nhiều thứ sẽ không được dạy trên trường, nhiều thứ không được nói đến nhưng lại khá quan trọng trong thực tiễn, đó là việc viết commit message git. Trước giờ thì các commit của mình thì chỉ đặt theo chức năng của đoạn code đó thôi, mỗi lúc mỗi kiểu, không theo một chuẩn nào cả. Sau này lúc tìm lại thấy nó rối tung, rối mù luôn, rất là khó chịu.

Vậy tại sao cần một tiêu chuẩn chung cho các commit messages

Việc có một tiêu chuẩn chung cho các commit messages mang lại nhiều lợi ích quan trọng trong quản lý mã nguồn:

1. Dễ đọc và hiểu: Tiêu chuẩn giúp tạo ra các commit message dễ hiểu và mạch lạc hơn, giúp các thành viên trong nhóm dễ dàng nắm bắt được ý nghĩa của mỗi commit.
2. Dễ quản lý: Các commit message tuân thủ tiêu chuẩn giúp quản lý lịch sử thay đổi mã nguồn trở nên dễ dàng hơn. Khi cần tìm kiếm thông tin cụ thể hoặc xác định nguyên nhân của một vấn đề, các message theo tiêu chuẩn giúp tiết kiệm thời gian và công sức.
3. Tạo điều kiện cho tự động hóa: Các commit message theo tiêu chuẩn thường chứa thông tin có thể được sử dụng để tự động hóa quy trình phát triển, như việc tạo ra bản phát hành tự động hoặc sinh tài liệu tự động.
4. Tăng tính chuyên nghiệp: Giúp tạo ra một ấn tượng tích cực đối với người sử dụng dự án
5. Tạo cơ sở cho hợp tác: Tiêu chuẩn commit message tạo điều kiện cho việc hợp tác hiệu quả hơn giữa các thành viên trong nhóm, đặc biệt là khi có nhiều người tham gia vào dự án.

Conventional Commits

Conventional Commits là một tiêu chuẩn cho các commit message được thiết kế để tạo ra các message dễ đọc và dễ quản lý trong quá trình phát triển phần mềm. Các commit message theo tiêu chuẩn này bao gồm ba phần chính: loại commit, phạm vi và mô tả chi tiết về thay đổi.

Sử dụng Conventional Commits giúp tạo ra các commit message có cấu trúc, dễ đọc và dễ quản lý. Điều này giúp tăng tính chuyên nghiệp của dự án, tạo điều kiện cho việc tự động hóa quy trình phát triển, và hỗ trợ việc hợp tác giữa các thành viên trong nhóm một cách hiệu quả.

Cấu trúc của commit message

Dưới đây là cấu trúc chung của một commit message theo conventional:

<type>[optional scope]: <description>

[optional body]

[optional footer]

Trong đó:

• Các thành phần type, description là bắt buộc
• Optional là tùy chọn có hoặc không có cũng được
• type: từ khóa để phân loại commit là feature, fix bug, refactor.
• scope: cũng được dùng để phân loại commit, vùng ảnh hưởng của commit
• description: là mô tả ngắn về những gì sẽ bị sửa đổi trong commit đấy
• body: là mô tả dài và chi tiết hơn, cần thiết khi description chưa thể nói rõ hết được, có thể thêm phần ghi chú bằng các keyword
• footer: một số thông tin mở rộng như số ID của pull request, issue.. được quy định theo conventional

Ví dụ cụ thể:

feat(auth): add JWT authentication middleware

- Implemented JWT middleware for user authentication
- Added token generation and verification functions
- Integrated middleware with user authentication endpoints

Closes #123

Một số type phổ biến được khuyên sử dụng bao gồm:

• feat: thêm một feature
• fix: fix bug cho hệ thống, vá lỗi trong codebase
• refactor: sửa code nhưng không fix bug cũng không thêm feature hoặc đôi khi bug cũng được fix từ việc refactor.
• docs: thêm/thay đổi document
• chore: những sửa đổi nhỏ nhặt không liên quan tới code
• style: những thay đổi không làm thay đổi ý nghĩa của code như thay đổi css/ui chẳng hạn.
• perf: code cải tiến về mặt hiệu năng xử lý
• vendor: cập nhật version cho các dependencies, packages.

Tham khảo

https://www.conventionalcommits.org/en/v1.0.0/