Conventional Commits
Tại sao cần thiết?
Tự động tạo ra các changelogs
Tự động xác định ngữ cảnh của một phiên bản
Truyền đạt bản chất của những thay đổi cho đồng đội, công chúng và các bên liên quan khác.
Tạo văn hóa và quy trình chuyên nghiệp làm việc nhóm
Làm cho mọi người dễ dàng đóng góp cho các dự án của bạn, bằng cách cho phép họ khám phá một lịch sử commit có cấu trúc hơn.
Commit nên được cấu trúc như sau:
Trong đó:
Các thành phần type, description là bắt buộc cần có trong commit message, 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, refactor,...
scope: cũng được dùng để phân loại commit, vùng ảnh hưởng của commit, trả lời câu hỏi: commit này refactor, fix cái gì? được đặt trong cặp ngoặc đơn ngay sau type. VD: feat(authentication):, fix(parser):
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
Một số type phổ biến:
feat
: thêm một tính năng mớifix
: fix bug cho hệ thống, vá lỗi trong codebaserefactor
: 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 documentchore
: Những sửa đổi nhỏ nhặt không liên quan tới codestyle
: 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.test: Thêm unitest hoặc thực hiện hành động test thành công
ci: Thay đổi file cấu hình CI
revert: Đảo ngược về commit cũ
drop: Xóa folder / file trong codebase
Một số ví dụ điển hình:
Thêm tính năng thanh toán
Sửa lỗi xác thực mã thanh toán
type thêm ! Để thu hút sự chú ý đến việc phá vỡ sự thay đổi
Commit với body dài và nhiều footer
Đảo ngược về một commit cũ
Last updated