💻
Tech notes
  • Các nguyên tắc trong kiến trúc phần mềm
  • Vòng đời phát triển phần mềm SDLC
  • 6 nguyên lý thiết kế microservices
  • MLOps Roadmap
  • SBOMs là gì?
  • Thuật thức hơi thở của Review Code
  • Tại sao code lại bốc mùi thối?
  • Corner testcase là gì?
  • So sánh mô hình Scrum và mô hình waterfall, Sprial
  • Quy trình release phiên bản phần mềm
  • 12 tuyên ngôn Agile
  • Conventional Commits
  • Chatgpt Prompt for coder
  • Quản trị dữ liệu
  • Nợ kỹ thuật
  • So sách Data-Centric và Model-Centric
  • Tracking Evaluation Measures
  • Mô hình Kano
  • Clean Code with C++ in cxview.ai
  • Các mức độ rủi ro về technical debt
  • Phiếu tự đánh giá cho hệ thống sản xuất học máy
  • Quản lý chất lượng trong ML
Powered by GitBook
On this page

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:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

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ới

  • 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.

  • 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

feat: add payment feature

Sửa lỗi xác thực mã thanh toán

fix(payment): fix validate of payment code

type thêm ! Để thu hút sự chú ý đến việc phá vỡ sự thay đổi

feat(api)!: send an email to the customer when a product is shipped

Commit với body dài và nhiều footer

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Đảo ngược về một commit cũ

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868
Previous12 tuyên ngôn AgileNextChatgpt Prompt for coder

Last updated 2 years ago