Những Cách Tốt Nhất Để Viết Tin Nhắn Cam Kết Git: Giống Như Các Chuyên Gia

Khi một nhà phát triển quay ngược thời gian để tìm kiếm điều gì đó anh ta đã làm cách đây sáu tháng, nhiều lần anh ta không hiểu tại sao mình lại thực hiện cam kết cụ thể đó, và lý do duy nhất cho điều đó là vì anh ta đã không tuân theo cách đúng đắn để viết thông điệp cam kết.

\ Có những tiêu chuẩn thông điệp cam kết mà các nhà phát triển thực hành trên toàn thế giới, và việc tuân theo các tiêu chuẩn phổ biến là tốt để khi bạn quay lại sau một khoảng thời gian dài hoặc khi người khác nhìn vào thông điệp cam kết của bạn, chúng sẽ không trông kỳ quặc!

\

\ Các nhóm nên quyết định trước về quy ước thông điệp cam kết để xác định lịch sử kiểm soát phiên bản của sản phẩm họ đang xây dựng.

\ Một thông điệp cam kết Git tuyệt vời nên có phong cách, nội dung và siêu dữ liệu phù hợp.

\ Một cam kết Git phổ biến tuân theo quy ước này:

<type>(<scope>): <message>

\ <type> có thể là một trong những điều sau đây:

• feat cho một tính năng mới.
• refactor cho việc tái cấu trúc mã sản xuất, ví dụ: đổi tên một hàm.
• docs cho các thay đổi về tài liệu.
• fix cho việc sửa lỗi cho người dùng.
• perf cho các cải tiến hiệu suất.
• style cho các thay đổi định dạng, thiếu dấu chấm phẩy, v.v.
• test cho việc thêm các bài kiểm tra còn thiếu, tái cấu trúc các bài kiểm tra.
• build cho việc cập nhật cấu hình xây dựng, công cụ phát triển hoặc các thay đổi khác không liên quan đến người dùng.

\ Bạn cũng có thể thêm kiểu tùy chỉnh của mình, tùy thuộc vào tiêu chuẩn mà nhóm của bạn tuân theo. Các tiêu chuẩn trên được nhóm ESLint tuân theo. Bạn có thể kiểm tra thông điệp cam kết của họ tại đây.

\ Phạm vi là tùy chọn, và phần thông điệp nên bao gồm một câu đơn dòng, không quá 72 ký tự, để tóm tắt cam kết là để làm gì.

\ Nhiều nhà phát triển cũng sử dụng thông điệp như dòng tiêu đề và thêm phần thân; đó về cơ bản là mô tả của cam kết, nhưng một thông điệp cam kết một dòng là ưu tiên miễn là bạn có thể hiểu ngữ cảnh (cam kết là gì và tại sao). Nếu cam kết đòi hỏi một mô tả chi tiết hơn không thể giải thích trong một dòng, phần thân cam kết luôn cần thiết.

\ Bạn cũng có thể sử dụng các công cụ như Glitter hoặc Commitizen để chuẩn hóa thông điệp cam kết của mình.

\ Không chỉ vậy, bạn cũng có thể tự hỏi liệu có công cụ nào kiểm tra thông điệp cam kết của bạn và hiển thị lỗi nếu nó không tuân theo hướng dẫn. Commit lint là một trong số đó. Nó giúp nhóm của bạn tuân thủ quy ước cam kết.

\ Nhiều lần, các chuyên gia trong ngành sử dụng ticket JIRA hoặc Click Up của họ làm thông điệp cam kết để mọi thứ có thể được liên kết hoặc truy nguyên bất cứ lúc nào, và cơ sở mã vẫn có thể bảo trì cho các nhà phát triển trong tương lai.

\ Một số nhóm cũng thích thêm biểu tượng cảm xúc vào thông điệp cam kết của họ. Tôi đã tổng hợp một danh sách các biểu tượng cảm xúc và ý nghĩa tương ứng của chúng. Bạn có thể xem nó tại đây.

\ Cuối cùng, điều quan trọng là thông điệp cam kết của bạn phải có ý nghĩa và không làm nhầm lẫn các nhà phát triển đồng nghiệp hoặc các nhà phát triển trong tương lai về một thay đổi cụ thể là gì.

\ Nếu bạn muốn tìm hiểu thêm về cam kết thông thường, cam kết ngữ nghĩa, hoặc các thực hành mà ngành công nghiệp tuân theo, đây là một số tài nguyên cho bạn:

1. Conventional Commits
2. Semantic Commits
3. How to write a commit message by CBeams

\